
“Most serious” Linux privilege-escalation bug ever is under active exploit - saidajigumi
http://arstechnica.com/security/2016/10/most-serious-linux-privilege-escalation-bug-ever-is-under-active-exploit/#p3
======
the_duke
Seems to be fixed by this commit (in 4.8.3).

commit 89eeba1594ac641a30b91942961e80fae978f839 Author: Linus Torvalds
<torvalds@linux-foundation.org> Date: Thu Oct 13 13:07:36 2016 -0700

    
    
        mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
        
        commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 upstream.
        
        This is an ancient bug that was actually attempted to be fixed once
        (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix
        get_user_pages() race for write access") but that was then undone due to
        problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").
        
        In the meantime, the s390 situation has long been fixed, and we can now
        fix it by checking the pte_dirty() bit properly (and do it better).  The
        s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement
        software dirty bits") which made it into v3.9.  Earlier kernels will
        have to look at the page state itself.
        
        Also, the VM has become more scalable, and what used a purely
        theoretical race back then has become easier to trigger.
        
        To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
        we already did a COW" rather than play racy games with FOLL_WRITE that
        is very fundamental, and then use the pte dirty flag to validate that
        the FOLL_COW flag is still valid.

~~~
flukus
So it's been a known bug for 11 years? That sounds like a pretty serious issue
with the QA and or bug tracking process.

~~~
empath75
It sounds like it wasn't realistically exploitable until recently.

------
ontoillogical
At Appcanary, we're thinking about opening up our vulnerability database to be
browsable and searchable by the public. If you're not sure which version has
the patch for this vulnerability in your distro, here's what we know:

Ubuntu -
[https://appcanary.com/vulns/45984](https://appcanary.com/vulns/45984)

Debian -
[https://appcanary.com/vulns/45983](https://appcanary.com/vulns/45983)

Amazon Linux -
[https://appcanary.com/vulns/45992](https://appcanary.com/vulns/45992)

Centos - no patch yet

If you found this useful, please let me know!

~~~
ndesaulniers
Do you keep track of Android releases?

edit: [https://appcanary.com/vulns](https://appcanary.com/vulns) made my
browser crawl. Please fix that page.

~~~
microcolonel
I think you just need more RAM, it's convenient having it all on one page
instead of paginated.

~~~
ndesaulniers
Do you know any good sites where I could download some more? ;)

~~~
Natanael_L
I think there's some FPGA code somewhere to emulate external RAM...

------
tptacek
_It 's probably the most serious Linux local privilege escalation ever._

Look, the Azimuth people have forgotten more about reliable exploit
development than I have ever known, but, no, as stated, this is clearly not
true. Not long ago, pretty much all local privesc bugs were practically 100%
reliable.

What I think they mean to say is that this is unusually reliable for a kernel
race.

I still think, though, that the right mental model to have regarding Linux
privesc bugs is:

1\. If there's a local privesc bug with a published exploit, assume it's 100%
reliable.

2\. In almost all cases, whether or not there's a known local privesc bug,
assume that code execution on your Linux systems equates to privesc; this is
doubly true of machines in your prod deployment environment.

~~~
qwertyuiop924
You said it: If you are not explicitly on the business of providing external
access to your machine, the privesc isn't your problem (it's a problem, and
it's bad, though), it's the fact that anybody could exploit the privesc in the
first place.

~~~
throwaway2048
no, because a bug like this turns any code execution exploit into remote
root...

~~~
tptacek
The point is that code execution is almost always remote root, because lots of
bugs like this exist. Also: most engineers overestimate the relative value of
root vs. simple inside-the-VPC code execution, which is almost always gameover
anyways.

~~~
patio11
Thomas has elaborated on this a few times over the years, but to elaborate for
people who weren't around for those conversations: if you can make an HTTP
request from inside the firewall, which probably doesn't require root, you can
pivot the attack to a variety of internal services which are not designed with
security in mind. That could let you e.g. reconfigure networking appliances,
grab credentials to internal or external services from DevOps-y credential
stores, grab all manner of business secrets, pivot to direct SQL access to the
DB laundered through e.g. internal analytics dashboards or admin tooling, etc.

------
drieddust
>However that's hard to do when the vast majority of kernel bugs come from
vendor drivers, not the upstream Linux kernel, Stoep said.

Doesn't this actually validate Andrew Tannenbaum's argument[1] over 25 years
ago when he said monolithic operating systems are inherently insecure and a
rethink is required.

[1]
[https://groups.google.com/forum/m/?fromgroups#!topic/comp.os...](https://groups.google.com/forum/m/?fromgroups#!topic/comp.os.minix/wlhw16QWltI)

~~~
kentonv
Looks like you are quoting from:
[http://arstechnica.com/security/2016/09/linux-kernel-
securit...](http://arstechnica.com/security/2016/09/linux-kernel-security-
needs-fixing/)

While it's true that vendor drivers living in kernel space is horrible for
security... that's somewhat offtopic here. This particular bug is in the
memory management system, which is one of those things that kind of has to be
in the kernel. A microkernel architecture seemingly would not have helped in
this particular case.

~~~
snvzz
> This particular bug is in the memory management system, which is one of
> those things that kind of has to be in the kernel.

Not really. L4 family (the post-Liedtke world) and Minix3 both have MM out of
the kernel.

~~~
AstralStorm
A privilege escalation in MM daemon would still allow you to write and read
any user memory. Just not kernel memory or execute anything not covered by
memory access capabilities. For nearly all intents and purposes, it is root.

~~~
snvzz
Couple things here.

Firstly, as the MM daemon runs on its own process and is well-separated from
other code, it is far easier to audit, debug and so on. Its interface is also
entirely explicit. There's value in modular programming. It's far more
reasonable to expect quality from such a MM daemon than the mess in a random
monolith kernel.

Secondly, in seL4, physical pages are capabilities. There might be more than
one MM daemon, owning separate sets of capabilities to physical pages.
Security-critical memory might be managed by a MM daemon your vulnerable
process has no capability to talk to.

Just my two cents.

------
aexaey

      CVE-2016-5195
    
      This flaw allows an attacker with a local system account to
      modify on-disk binaries, bypassing the standard permission
      mechanisms that would prevent modification without an
      appropriate permission set. This is achieved by racing the
      madvise(MADV_DONTNEED) system call while having the page of
      the executable mmapped in memory.
    

Excellent example why mounting partition with system binaries (such as /usr)
read-only is a good idea. CoreOS does this.

[EDIT] added "read-only"

~~~
kentonv
As others have pointed out, mounting read-only wouldn't have helped here.

What would have helped:

* Block ptrace() syscall using seccomp.

* Don't mount /proc, or mount it read-only.

As I understand it, those steps would close all attack vectors for this bug.

FWIW, the Sandstorm.io sandbox blocks ptrace() and doesn't mount /proc at all,
so I think the bug has never been exploitable by Sansdtorm apps. (Disclosure:
I am the tech lead of Sandstorm.)

I think Docker now defaults to mounting /proc read-only and blocking ptrace(),
so it may mitigate this vulnerability as well, but I'm not 100% sure about
that.

~~~
AstralStorm
Ptrace is not needed for an exploit, you only need to be able to mmap a file.
Does not even have to be writable.

~~~
kentonv
No, it's more complicated than that. You need one process to mmap a file, and
then you need a second process to be writing into the first process's address
space while the first process triggers the COW. You can't do it with one
process attacking itself.

~~~
amscanne
No, it requires only two threads to trigger the race. Two processes are not
needed.

~~~
kentonv
[https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13](https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13)

> _Please note that this mitigation disables ptrace functionality which
> debuggers and programs that inspect other processes (virus scanners) use and
> thus these programs won 't be operational._

> _The in the wild exploit we are aware of doesn 't work on Red Hat Enterprise
> Linux 5 and 6 out of the box because on one side of the race it writes to
> /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise
> Linux 5 and 6._

Is everyone barking up the wrong tree here?

EDIT: All of the PoCs here use ptrace() or /proc/self/mem. Why would they do
that if they didn't need to?

[https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs](https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs)

~~~
kentonv
I just talked to amluto who explained that the race can only be triggered by a
write that uses the "force" flag to get_user_pages() (a kernel function).
/proc/pid/mem and ptrace() do this but regular writes and process_vm_writev()
do not.

------
saidajigumi
See also the dedicated page for this vulnerability, dubbed Dirty COW (for
copy-on-write), aka CVE-2016-5195:

[http://dirtycow.ninja/](http://dirtycow.ninja/)

~~~
vesinisa
Gotta love the dedication with the Dirty COW "swag" web shop and all. Though
something tells to me it's just a strange in-joke. Might be the prices?
($1,000 for a mouse pad .. oh, really?)

~~~
kentonv
It would appear that the creators of the web site are not even affiliated with
the people who found or fixed the bug.

 _" Dirty COW is a community-maintained project for the bug otherwise known as
CVE-2016-5195. It is not associated with the Linux Foundation, nor with the
original discoverer of this vulnerability. If you would like to contribute go
to GitHub."_

Seems fishy.

~~~
Senji
We live in a world where slightly arcane developer jokes are "SWAG squatted"

------
escapologybb
Okay, I have no idea what to do. Not a security engineer, can't follow what
this thing does but I do have a couple of VPS's running my blog and a few
other things. Now maybe there's an argument that I shouldn't be doing this if
I don't completely understand all the ins and outs, but what the hell, I like
learning about Linux.

So my question is: is simply updating and upgrading enough to protect me from
this MOST DANGEROUS BUG EVER IN THE WORLD OH MY GOD YOU'RE GOING TO END UP
PART OF A BOTNET AND HURT LITTLE CHILDREN!!1!!1! Which is how this reads to
even a semi-technical reader, I mean I know my way around the command line but
I'm at a loss as to what to do here.

Help me out HN please!

------
cm3
Since for any serious bug that's published, there's very likely a dozen
private or not-yet-found, and also considering on how many networked devices
the linux kernel is used, I would really like to see a better upgrade story
for Android devices and any other linux-inside gear which doesn't have a
distro package manager to apply the fix. As little as I like obstructing tech
companies with more laws, especially since most laws don't understand the
tech, I feel like laws are the only pressure we can hope for. This is why the
abuse of IoT devices is a good thing. It will highlight how dangerous it is to
slap a random linux version in some device and never bother with updates. A
fleet of smart tvs needs to be hijacked with a stalker trojan that is then
used by people to record and later post online private moments of unsuspecting
owners of always standby smart tv, amazon echo networked microphones, etc.
It's just how the world works before it realize the risks and does something
about it.

As an engineer you can argue and plead with management to not release
something that you don't intend to provide timely updates with a well-
communicated support time. Like a 2 year warranty that's prominently
communicated, this would highlight to consumers that it's unsafe to use the
device unless disconnected from the network. Just like a car that doesn't pass
your local safety regulations is not allowed into public traffic.

Actually, I'm surprised modern cars do not require periodic zero-expenses-for-
the-owner software updates at licensed dealerships. You can explain to a
driver that tires go bad because they drove X miles and have to be paid for,
but you cannot argue that software updates need to be paid for because from
the time they bought it Y days have passed. Take the Samsung battery
optimization that went wrong, where the separation layer was a tiny bit too
shallow. It's fair to assume some regulation will follow for safety purposes.
Similarly, networked devices, which are not (and cannot be?) microcontrollers
with mere 500 lines of code, have to be regulated in terms of software
updates.

Now you may say the industry will go broke if they're required to provide
upgrades, or less devices will be made, but I think this will lead to
consolidation of the software stack, which is mostly a good thing, as those
who want to produce dozens of cheap IoT devices can do so without hiring
kernel developers. It's like other industries where cheap toy makers source
materials like plastic from vendors, knowing it's safe, or create the
materials following a detailed recipe which is certified.

~~~
necessity
That's assuming the distributor warranted you against vulnerabilities in his
product (and I remember seeing a "Distro X GNU/Linux comes with ABSOLUTELY NO
WARRANTY" on every device I've used...). Forcing said warranty is
preposterous.

Concerning smartphones there are so many privacy and security issues that are
far easier to exploit than something that involves kernel hacking... But
anyway, isn't Google rolling out security updates for Android? I use CM and I
know they don't. There are projects like Replicant which provide a mostly free
distribution, but I don't think they're rolling out security updates either.
If you're interested maybe contact them?

~~~
cm3
Are the system (not app) updates Google releases applicable to all Android
devices?

It's true that there are a high number of bugs available just in mobile
browsers, which do receive google play updates, if you have google play, but
viewing the underlying code as verified to be correct would be naive.

If I know that a smart phone or smart fridge will not get software updates and
be substantially limited in functionality by that, I wouldn't pay more than
100 bucks for it, because I expect to buy another one in probably 14 months.

However, if the update problem would be fixed properly, I wouldn't mind paying
a premium.

It seems that this isn't just laziness by the vendors but also calculated into
nudging customers to buy new appliances and gadgets although the hardware is
capable and perfectly fine. No vendor would admit to that, but this is being
investigated and called planned obsolescence. If the price would reflect the
artificially limited lifespan of a device, then the problem goes away, and
it's just a matter how much of the materials gets recycled.

------
cheiVia0
Cool, this will be great for rooting Android phones to fix this and other
security bugs!

~~~
joelthelion
It's sad that anyone should have to rely on security bugs to take ownership of
their own phone...

~~~
biafra
These phones exist, because people are buying them. Other phones that allow
unlocking the bootloader also exist.

------
Unklejoe
Can someone help me better understand how this works, or perhaps point me to a
decent article explaining more of the details? Most of the articles I can find
just briefly explain the exploit, but not really how it works (in detail).

From looking at the example code, it seems like the general process is:

\- Open some (normally un-writable) file as read-only and mmap it in to your
process.

\- Kick off two threads. One thread to repeatedly write to the same mmap-ed
address via /proc/PID/mem and another thread to keep issuing the madvise call.

\- Wait for some race condition to be (un)satisfied such that you're able to
write to a cached copy of the file.

What I don’t fully understand is how the /proc/PID/mem thing works.

Here’s what I’m curious about:

1\. What would happen if you tried to write to the mmap-ed region directly?
Since it’s been mapped in with “PROT_READ”, does this mean that you’ll get a
segmentation fault or something? From the manpage, it seems like “MAP_PRIVATE”
allows it to be a COW mapping, but I don’t see how the combination of
“PROT_READ” and “MAP_PRIVATE” is even valid. Unless this means that any writes
to data copied from the mmap-ed region into other buffers will be COW-ed and
that you can’t actually write to the mmap-ed region itself? That would make
sense to me.

2.How is writing to /proc/PID/mem any different than writing through the mmap-
ed region directly? Assume that you weren’t running the madvice thread. What
would happen then if you tried to write to the /proc/PID/mem file? Presumably
the same thing that happens if you just tried to write to the file directly…

3\. Finally, how does the madvice call cause a race condition? I realize this
might be a little too much to cover in a comment, but this seems like the meat
of it.

------
kordless
Curious that the original commit's hash to fix this was never indexed by
Google:
[https://www.google.com/search?q=f33ea7f404e5&ie=utf-8&oe=utf...](https://www.google.com/search?q=f33ea7f404e5&ie=utf-8&oe=utf-8)

~~~
i336_
It is now, I see 16 results.

------
Hello71
Doesn't seem like it works on a $10 DigitalOcean droplet (1 vCPU) with grsec-
patched 4.4.8. After running for quite some time (which I suspect a system
administrator would notice) "cat foo" still outputs the same contents.

~~~
coldpie
How much is "quite some time"? It ran for several minutes before eventually
succeeding on my fast, modern desktop.

~~~
Hello71
The loops finished.

------
AznHisoka
I wish someone could explain in simpler terms to us casual users what this
means.

If only privileged users can SSH into my server, does this really affect me?
In other words, I already allow only SSH users to become root.

------
pbhjpbhj
If I'm reading this correctly it works only when there's already access to a
user account on the system. So you need to have an existing vulnerability
already [eg an untrusted user].

Interesting whether it will give new root exploits for Android as suggested in
the comments.

~~~
alltakendamned
Yes, that is exactly what a privilege escalation bug is.

------
winter_blue
If one's running an LTS version of Ubuntu like 14.04 or 16.04, can one can
expect to get an update with the security patch for this?

I'm running Kubuntu 14.04 with the latest security updates, and I'm still on
kernel version 3.13.0-98-generic.

    
    
        ~ $ lsb_release -a
        No LSB modules are available.
        Distributor ID: Ubuntu
        Description:    Ubuntu 14.04.5 LTS
        Release:        14.04
        Codename:       trusty
    
        ~ $ uname -a
        Linux anon-pc 3.13.0-98-generic #145-Ubuntu SMP Sat Oct 8 20:13:07 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
    

No idea why I haven't gotten an update to 4.x. Should I just switch to a
rolling release distro like Arch to have the latest updates of everything?

~~~
forbiddenlake
Hours ago. apt-get update && apt-get upgrade.

[https://www.ubuntu.com/usn/usn-3105-1/](https://www.ubuntu.com/usn/usn-3105-1/)
[http://people.canonical.com/~ubuntu-
security/cve/2016/CVE-20...](http://people.canonical.com/~ubuntu-
security/cve/2016/CVE-2016-5195.html)

~~~
winter_blue
It looks like my kernel updates are being held back:

    
    
        ~ $ sudo apt-get upgrade
        Reading package lists... Done
        Building dependency tree
        Reading state information... Done
        Calculating upgrade... Done
        The following packages have been kept back:
          ffmpeg libva1 linux-generic linux-headers-generic linux-image-generic
        0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
    

The newest available version of linux-image-generic according to apt-cache
showpkg is 3.13.0.100.108. (I'm running 3.13.0.98 right now.) Maybe 3.13.100
has the fix to this bug, but I'll have to figure out what's keeping back
linux-kernel-image from being updated.

What's really puzzling though is that I _should have kernle 4.4.x_ , since I'm
running Ubuntu 14.04.5, according to the Ubuntu Wiki:
[https://wiki.ubuntu.com/Kernel/Support#A14.04.x_Ubuntu_Kerne...](https://wiki.ubuntu.com/Kernel/Support#A14.04.x_Ubuntu_Kernel_Support)
It's strange that my Kubuntu installation is frozen on 3.13.x.

~~~
ivank
Note the "HWE" (hardware enablement) on that chart. Ubuntu 14.04 came with
3.13; if you want a 4.4 kernel, you have to install linux-generic-lts-xenial.

~~~
winter_blue
Thanks, that answers my question! Installing linux-generic-lts-xenial should
let me get the 4.4.x kernel on Ubuntu 14.04.

I might still switch to Arch Linux. It's been a hassle to get the latest
releases of various packages (like python, gcc, etc). I've had to use third-
party PPAs or manually install them. Ubuntu's freezing of packages makes it
great as a base image for Docker containers and other reliably reproducible
deployment scenarios, but that's not so great as a regular desktop user.

~~~
csdreamer7
I have been using Antergos (Desktop friendly Arch) on and off for a while. If
you haven't updated for a while, it could cause problems. After I updated
after staying off it for two months I had an x crash. Restarted, no problems,
all updates installed.

Chris from LAS does say I believe in User Error 6 or 7 that if you don't
update Arch in a while you could have stability issues when you update.

------
frederikvs
The github page [0] states that "The In The Wild exploit relied on using
ptrace." Now, I'm wondering what purpose ptrace serves, aside from debuggers?
Why don't we just disable this by default on production systems (where you
shouldn't be debugging anyhow)?

[0]
[https://github.com/dirtycow/dirtycow.github.io/wiki/Vulnerab...](https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails)

~~~
dllthomas
> production systems (where you shouldn't be debugging anyhow)

I'm not sure about this. Ideally, yes, but if you don't know what's causing an
issue it can be difficult to reproduce it, and strace can be phenomenally
helpful in figuring out the cause. Of course, you could leave it off until you
think you might be in such a situation.

------
100ideas
Go go armlinux Internet of Things bot army!

------
fulafel
So the escalation is rw access to privileged files, are LXC and Docker
container breakouts prevented then? Also does /proc access through lxcfs or
Docker's handling of /proc make any difference?

~~~
antocv
Theoretically, no. LXC or docker will not help against this. Not even against
this particular exploit seen in the wild, but that could be mitigated with lxc
(maybe docker), partically lxc.container.conf you can set seccomp to drop
ptrace syscall which this wild exploit depends on.

Here, it really is a difference between VM and container though.

~~~
benmmurphy
It might protect against the current in-the-wild exploit. It sounds like it
modifies a binary/library so if the container doesn't share binaries/libraries
with other containers or the root namespace then you are fine. (well fine in
the sense that there is no privilege escalation from the container to outside
the container or across into another container.) However, there are other
interesting read only pages that are shared by everyone that might be targeted
(VDSO?).

------
ndesaulniers
I've filed a bug against Android Nexus/Pixel kernels. Will take a look
tomorrow. I'm sure someone else already beat me to the punch.

