Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 3 Nov 2016 15:26:54 +0000
From: Steve Grubb <>
To: Solar Designer <>
Subject: Re: CVE-2016-5195 "Dirty COW" Linux kernel privilege
 escalation vulnerability

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


> 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.)
> >
> >
> >
> >
> >
> >
> >
> >
> >  
> Alexander

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ