Date: Thu, 3 Nov 2016 15:26:54 +0000 From: Steve Grubb <sgrubb@...hat.com> To: Solar Designer <solar@...nwall.com> Cc: oss-security@...ts.openwall.com Subject: Re: CVE-2016-5195 "Dirty COW" Linux kernel privilege escalation vulnerability On Wed, 26 Oct 2016 21:13:57 +0200 Solar Designer <solar@...nwall.com> wrote: > 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) I am curious. Can anyone think of a good reason why /proc/self/mem _should_ be writable? I can understand the needs of debuggers to access other processes. But writing to yourself just doesn't seem like a normal use. PTRACE_POKEDATA should be covered by yama security controls. I wonder if /proc/self/mem should also be under the yama security control. Thoughts? -Steve > 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
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