Re: CVE-2016-5195 "Dirty COW" Linux kernel privilege escalation vulnerability

[Steve Grubb <sgrubb () redhat com>]

On Wed, 26 Oct 2016 21:13:57 +0200
Solar Designer <solar () openwall 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