Dirty COW Vulnerability - Kernel Update Oct 21st

mehargags

I hope everyone is patched up for this very serious vulnerability called Dirty COW disclosed on October 19, 2016.

It is a privilege escalation vulnerability in the Linux Kernel existing since Kernel v2.6.22 thru which an attacker may gain write access to any file they can read, and then increase their privileges system-wide.

DO posted a nice How To Protect Your Server Against the Dirty COW Linux Vulnerability

Check your kernel version.
uname -rv

Anything below the versions stated below are vulnerable:

*4.8.0-26.28 for Ubuntu 16.10
*4.4.0-45.66 for Ubuntu 16.04 LTS
*3.13.0-100.147 for Ubuntu 14.04 LTS
*3.2.0-113.155 for Ubuntu 12.04 LTS
*3.16.36-1+deb8u2 for Debian 8
*3.2.82-1 for Debian 7
*4.7.8-1 for Debian unstable

##CentOS and Redhat are yet to release a patch fix.

My biggest concern is with OpenVZ Containers... What is the remedy for OVZ as they are all stuck at Kernel 2.6?

Flapadar

@mehargags said:

My biggest concern is with OpenVZ Containers... What is the remedy for OVZ as they are all stuck at Kernel 2.6?

My understanding is that this exploit cannot be used for container or virt breakout. I've also heard RHEL 6 is unaffected.

rivermigue

Affected kernel versions in RHEL6 are located in the DO post mentioned by the OP. RHEL 6 is affected.

https://access.redhat.com/sites/default/files/rh-cve-2016-5195_1.sh

Foul

Partial Mitigation Resolution

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

Petr Matousek 2016-10-19 12:16:23 EDT
Please note that this mitigation disables ptrace functionality which
debuggers and programs that inspect other processes (virus scanners)
use and thus these programs won't be operational.

Also this mitigation works against the In The Wild (ITW) exploit we are aware of but most likely does not mitigate the issue as a whole.

To mitigate the issue:


1) On the host, save the following in a file with the ".stp" extension:

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")
}


2) Install the "systemtap" package and any required dependencies. Refer
to the "2. Using SystemTap" chapter in the Red Hat Enterprise Linux
"SystemTap Beginners Guide" document, available from docs.redhat.com,
for information on installing the required -debuginfo and matching kernel-devel packages

3) Run the "stap -g [filename-from-step-1].stp" command as root.

If the host is rebooted, the changes will be lost and the script must be
run again.


Alternatively, build the systemtap script on a development system with
"stap -g -p 4 [filename-from-step-1].stp", distribute the resulting
kernel module to all affected systems, and run "staprun -L <module>" on those.
When using this approach only systemtap-runtime package is required on
the affected systems. Please notice that the kernel version must be the same
across all systems.

KuJoe

If you're running KernelCare then this was patched yesterday for most kernels: https://www.cloudlinux.com/kernelcare-blog/entry/dirty-cow-vulnerability-the-fix-is-coming

mehargags

@KuJoe said:
If you're running KernelCare then this was patched yesterday for most kernels: https://www.cloudlinux.com/kernelcare-blog/entry/dirty-cow-vulnerability-the-fix-is-coming

So does that mean even if my OVZ VPS is running :
2.6.32-44-pve #1 SMP Mon Jan 25 13:03:39 CET 2016

I am not affected ?

Just got a ticket reply from my provider saying "OpenVZ is not affected by this. You are safe."

What does that mean ? If its a kernel level exploit and some gains access to my public web app, he cannot gain privileged access ?

I seriously doubt the "layers" we are talking about

Awmusic12635

@mehargags

Well also if the provider is using kernel care the actual kernel patch version wouldn't show.

AnthonySmith

mehargags said: So does that mean even if my OVZ VPS is running : 2.6.32-44-pve #1 SMP Mon Jan 25 13:03:39 CET 2016

I dont think kernelCare provide kernel patching for Proxmox

Awmusic12635

@AnthonySmith said:

mehargags said: So does that mean even if my OVZ VPS is running : 2.6.32-44-pve #1 SMP Mon Jan 25 13:03:39 CET 2016

I dont think kernelCare provide kernel patching for Proxmox

They do, we use it

deadbeef

$ ./rh-cve-2016-5195_1.sh 
Your kernel is 4.6.4-1.el7.centos.x86_64 which is NOT vulnerable.

# ./rh-cve-2016-5195_1.sh 
Your kernel is 4.8.1-1.el7.centos.x86_64 which is NOT vulnerable.

Confused Shouldn't they be vulnerable?

*Edit: For the second one, I suppose I misunderstood the "centos has not released a fix yet" part.

AnthonySmith

Awmusic12635 said: They do, we use it

excuse me, I am eating a hat right now.

eva2000

@deadbeef said:
$ ./rh-cve-2016-5195_1.sh
Your kernel is 4.6.4-1.el7.centos.x86_64 which is NOT vulnerable.

# ./rh-cve-2016-5195_1.sh
Your kernel is 4.8.1-1.el7.centos.x86_64 which is NOT vulnerable.

Confused Shouldn't they be vulnerable?

*Edit: For the second one, I suppose I misunderstood the "centos has not released a fix yet" part.

the detection script is too basic it just checks against known centos/rhel provided kernel versions to see if you're vulnerable. If you use elrepo or other non-rhel/centos provided kernel versions then the detection doesn't work

standard centos 7 kernel

./rh-cve-2016-5195_1.sh
Your kernel is 3.10.0-327.36.1.el7.x86_64 which IS vulnerable.
Red Hat recommends that you update your kernel. Alternatively, you can apply partial
mitigation described at https://access.redhat.com/security/vulnerabilities/2706661 .

elrepo 4.7.5kernel isn't detected as vulnerable because the detection script isn't looking for that kernel version

./rh-cve-2016-5195_1.sh
Your kernel is 4.7.5-1.el7.elrepo.x86_64 which is NOT vulnerable.

similarly linode fixed 4.8.3 kernel for this flaw isn't detected

./rh-cve-2016-5195_1.sh
This script is only meant to detect vulnerable kernels on Red Hat Enterprise Linux 5, 6 and 7.

mehargags

@Awmusic12635 said:
Well also if the provider is using kernel care the actual kernel patch version wouldn't show.

So what Kernel Version are you using exactly ?

I guess the providers should mail all customers informing them as there will be many who will feel "unsafe" not being able to go past v2.6 after an apt-get upgrade.

Awmusic12635

mehargags said: So what Kernel Version are you using exactly ?

Looks like

kpatch-description: 8;2.6.32-47-pve_2.6.32-179

rincewind

If you want to test for the vulnerability, PoCs is a better resource.

The mitigation code that I have seen so far block against the one known exploit in the wild that uses /proc/self/mem.

https://github.com/scumjr/dirtycow-vdso escapes containers and SELinux.

mik997

@mehargags said:

thanks for heads up - all patched

Razza

Useing Grsecurity kernel test patch's, no sure when this was fixed, but the Grsecurity patched kernel i built on the 7 Oct using kernel 4.7.6, i've tried ever Poc none of them seem to be working.

Edit

It seem that one's based on /proc/self/mem are non working, but one's useing PTRACE_POKEDATA seem to still work fine.

kaflo

@Awmusic12635 said:
kpatch-description: 8;2.6.32-47-pve_2.6.32-179

sea2 says 2.6.32-43-pve #1 SMP Tue Oct 27 09:55:55 CET 2015

so it's still vulnerable?

Awmusic12635

@kaflo said:

@Awmusic12635 said:
kpatch-description: 8;2.6.32-47-pve_2.6.32-179

sea2 says 2.6.32-43-pve #1 SMP Tue Oct 27 09:55:55 CET 2015

so it's still vulnerable?

I believe I said this earlier, kernelcare doesn't show the new version via the uname command. You can only see what the live patched version is by running the kernel care command, which only works on the host node.

rivermigue

Interesting comment taken from https://bugzilla.redhat.com/show_bug.cgi?id=1384344

The in the wild exploit we are aware of doesn't work on Red Hat Enterprise Linux 5 and > 6 out of the box because on one side of the race it writes to /proc/self/mem, but >/proc/self/mem is not writable on Red Hat Enterprise Linux 5 and 6.

AnthonySmith

I might be completely barking up the wrong tree but I had a further look in to it myself, this seems very similar to the XSA that caused amazon to reboot not so long ago with the big embargo on Xen.

qrwteyrutiyoup

@rivermigue said:
Interesting comment taken from https://bugzilla.redhat.com/show_bug.cgi?id=1384344

The in the wild exploit we are aware of doesn't work on Red Hat Enterprise Linux 5 and > 6 out of the box because on one side of the race it writes to /proc/self/mem, but >/proc/self/mem is not writable on Red Hat Enterprise Linux 5 and 6.

There's a different flavor of exploit in the wild that does not use /proc/self/mem, but relies on ptrace instead. @Razza reported above that the ptrace-variants seem to be still working.

ricardo

Am I right in thinking this isn't a vulnerability that can be exploited over the net? For pretty much all the servers I run, I'm the sole command line user.

AnthonySmith

ricardo said: Am I right in thinking this isn't a vulnerability that can be exploited over the net? For pretty much all the servers I run, I'm the sole command line user.

I believe the exploit requires some sort of shell access even if limited or at least the ability to exec something and access to 'a file'

deadbeef

@rincewind said:
https://github.com/scumjr/dirtycow-vdso escapes containers and SELinux.

I need to congratulate the author of that page for the excellent title chosen.

deadbeef

What baffles me is the absence of a proper fix. If the problem has been disclosed, why is there no effective patch yet? Is it a design issue and can't be patched?

Ole_Juul

deadbeef said: What baffles me is the absence of a proper fix.

I thought that most distros had the kernel patched and you just need to do an update. It's the routers and other devices that are a problem. You might like the El Reg article, Dirty Cow Explained.

deadbeef

@Ole_Juul said:
I thought that most distros had the kernel patched and you just need to do an update.

Idk, the guys above said that the patch is for the specific implementation found on the wild and different implementations still exploit this fine. I.e. the root cause is unfixed.

It's the routers and other devices that are a problem.

Don't you need a local account to use this exploit?

mik997

"although it is a local privilege escalation bug, remote attackers can use it in conjunction with other exploits that allow remote execution of non-privileged code to achieve remote root access on a computer"

arstechnica.com/security/2016/10/most-serious-linux-privilege-escalation-bug-ever-is-under-active-exploit/

rincewind

deadbeef said: Is it a design issue and can't be patched?

This specific bug is a race condition with copy-on-write pages, but the real problem is the madvise(., MADV_DONTNEED) call which is a design issue.

ricardo said: Am I right in thinking this isn't a vulnerability that can be exploited over the net?

The first exploit known was an SQL injection sent over the net. The real problem is that it is almost impossible to block - it makes a mockery of all the usual protection mechanisms.

ricardo

SQL injection

As I understand it, it's going to require a lapse in security like that (where the system is likely to get owned anyway), or a mechanism that allows a user to create a file and execute it.