Date: Wed, 26 Oct 2016 21:13:57 +0200 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: CVE-2016-5195 "Dirty COW" Linux kernel privilege escalation vulnerability On Fri, Oct 21, 2016 at 02:31:04AM +0200, Solar Designer wrote: > This was brought to the linux-distros list (and briefly inadvertently to > the distros list, although discussion continued on linux-distros only) > on October 13 and it was made public yesterday, so it must be in here as > well. Unfortunately, no one posted about it in here so far (the person > who brought this to [linux-]distros must have done so!), and I don't > have time to make a proper posting (with full detail in the message > itself, as per oss-security list content guidelines), but I figured it's > better for me to post something than nothing at all. > > Red Hat's description: > > "A race condition was found in the way the Linux kernel's memory > subsystem handled the copy-on-write (COW) breakage of private read-only > memory mappings. An unprivileged local user could use this flaw to gain > write access to otherwise read-only memory mappings and thus increase > their privileges on the system." A lot was said about this vulnerability in lots of places, so I won't dare to try and repeat all or post it in here (sorry!) Many exploits exist now, as summarized at: https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs The exploits vary in whether they use /proc/self/mem (newer kernels only) or PTRACE_POKEDATA (both newer and older kernels) and in what they target: generic read-only write, SUID root program, libc, or vDSO. All of them (that I've seen) also use MADV_DONTNEED. vDSO appears to be the scariest target in that it allows for sandbox or container escape without requiring any other sharing with the outside world (no shared files, no KSM). Some kernels have sysctl's (varying across kernel versions and architectures) that allow to disable vDSO on a live system, but keep in mind that already-started processes retain their vDSOs and may in many scenarios be used for the attack. Also, disabling vDSO does nothing to prevent attacks targeting something else (same sandbox/container or other page sharing with the outside). Luckily, many sandboxes exclude /proc and ptrace, which so far prevents all of these exploits from working. Surprisingly (to me), the published exploits appear to work as-is even on systems with only one logical CPU (except on RHEL5 and alikes, where 2+ CPUs appear to be needed, but don't count on this). Here are a couple of challenges by me (and whoever is behind the DirtyCow website kindly backed these with prizes of t-shirts priced at thousands of dollars each): 1. Exploit DirtyCow without MADV_DONTNEED. 2. Exploit DirtyCow on RHEL5 with only 1 logical CPU. and here's a new obvious one I add just now: 3. Exploit DirtyCow without /proc/self/mem _and_ without PTRACE_POKE*. Bonus points if you achieve several of these in one exploit. Many distros have released updates by now. This includes RHEL7 & RHEL6, but (as far as I can tell) not yet RHEL5. Since these legacy kernels still matter to me and possibly to others, attached are two patches for RHEL5'ish OpenVZ kernels, which should be reusable on other RHEL5-alikes. rhel5-owl-dirtycow.diff is what went into the kernel updates we released for Owl a couple of days ago - it is a mitigation for MADV_DONTNEED and PTRACE_POKE*, protecting both through write-locking mmap_sem (thus, against each other as well as against other code paths that read-lock mmap_sem). rhel5-openvz-dirtycow.diff is interdiff between OpenVZ's older "-408.el5.028stab120.2" kernels and "-408.el5.028stab120.3" they just released today. Unlike the mitigation in Owl, this is a backport of the fix from newer kernels. I have yet to test this one myself. (I briefly tried to produce a backport as well, but gave up after my half-baked attempts failed testing. I see this patch does at least one thing that I missed in my backport attempts. Kudos to OpenVZ project, who had also released updates for their newer kernels.) These two patches can also be reasonably used together. (I think we'll do just that in Owl, assuming that OpenVZ's fix passes our testing. And yes, Owl is essentially a legacy system now, arguably having served its purpose years ago, but we still maintain it for some deployments.) > https://access.redhat.com/security/cve/cve-2016-5195 > https://bugzilla.redhat.com/show_bug.cgi?id=1384344 > https://security-tracker.debian.org/tracker/CVE-2016-5195 > http://www.v3.co.uk/v3-uk/news/2474845/linux-users-urged-to-protect-against-dirty-cow-security-flaw > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 > https://lkml.org/lkml/2016/10/19/860 > https://dirtycow.ninja > https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails > https://twitter.com/DirtyCOWVuln Alexander View attachment "rhel5-owl-dirtycow.diff" of type "text/plain" (1009 bytes) View attachment "rhel5-openvz-dirtycow.diff" of type "text/plain" (2754 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ