[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20161103152654.6200bbfd@ivy-bridge>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
