19 ms·

“Most serious” Linux privilege-escalation bug ever is under active exploit

483 points by saidajigumi 10y ago

aexaey 10y ago
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"
- geofft 10y ago
  Does this actually allow modifying the binary on disk, or just modifying the in-memory cached page? (i.e., is this a persistent attack that survives a reboot?)
  - startling 10y ago
    It's just the in-memory executable, as I understand it.
- anc84 10y ago
  How does having /usr on a seperate partition (if I understood you correctly) change the bug/exploit?
  - aexaey 10y ago
    Good point, edited to clarify.
- qwertyuiop924 10y ago
  Man, MADV_DONTNEED again? I mean, Linux's implementation is already weird (it behaves in a way counter to most other implementations of the call: you can see Bryan Cantrill's talk for the details). What is with that call?
  - SysArchitect 10y ago
    Found the lightning talk: https://youtu.be/bg6-LVCHmGM?t=3521 https://youtu.be/bg6-LVCHmGM?t=3521
    - xzion 10y ago
      Looking forward to a followup talk of him gloating now this bug has been reported
      - qwertyuiop924 10y ago
        I genuinely doubt he'll notice. Bryan, if you're reading this, it's merely because I doubt that you actually check Linux bugtrackers. Also, GNU tail provides tail -F, which does what you want tail -f to do. There is a reason for this. I don't remember what it is, but I think the manpage talks about it.
        i336_ 10y ago
        -F vs -f: -F figures out the new inode if the file is deleted (*notify are inode-based, if you see DELETE_SELF for a file you'll never get any more events)
        qwertyuiop924 10y ago
        ...which actually does handle truncation properly. For some reason.
        JdeBP 10y ago
        It's because IN_MODIFY covers both writing and truncation, so the code path for such an event has to handle both anyway. Ironically, given that you mention M. Cantrill, GNU tail does not really handle truncation properly, and gives up for almost the very case that M. Cantrill did: when the truncation doesn't decrease the size, or is very closely followed by a write that ends up not decreasing the size. Of course, truncation is not the best way to organize writing log files in the first place. daemontools family style log management (in cyclog, multilog, et al.) starts a fresh file whenever there is a rotation, so these problems of truncation never arise.
- Florin_Andrei 10y ago
  How does mounting the partition read-only help with modifying binary images in memory?
- startling 10y ago
  This exploit doesn't write to disk at all. It's about modifying the in-memory datastructures that correspond to executables on disk in between when they're read and executed.
- DSMan195276 10y ago
  I don't think that prevents this error. This exploit is all about gaining read-write access to a read-only page of memory. Mounting as read-only Might prevent the error, but only through extra checks of the dirty bit before pages are used (IE. The kernel would have to check the dirty bit on every page of a read-only file to ensure the contents were not changed through an exploit). The state of the disk and mounting of the disk generally wouldn't matter because the page is already being forced from read to read/write, and that has no barring on the mounting of or data on the actual disk. It doesn't matter if this data is actually flushed to the disk as long as the kernel uses it from cache without noticing it has been changed (Which it probably doesn't check regardless of read-only status).
- mjg59 10y ago
  Sadly, none of the security work we're doing would have helped in this case.
- peterwwillis 10y ago
  Fwiw, you should never think about an OS in terms of what security features they have enabled by default. The OS is almost always designed to help the user use programs and to help programs run. Just assume it is not secure until you do an audit + lockdown yourself. If you want a secure system by default, you should probably not use Linux. I would go with OSX or OpenBSD to start. (And finally: mounting /usr read-only isn't actually a security feature, because if you can exec code you can run a privesc and remount /usr read-write; mounting as noexec could arguably be considered a security feature)
  - ams6110 10y ago
    OSX? How is that more secure by default than Linux?
    - peterwwillis 10y ago
      Less published exploits. Okay, so "more secure" isn't exactly correct, maybe "more difficult for a 10 year old with Metasploit to own it"
      - vacri 10y ago
        Who'd've thought that an OS that is rarely used to serve remote content is more resilient against software focused on breaking into remote systems?
  - caf 10y ago
    OSX, really? It's had more than one privilege escalation exploitable from just a shell prompt (eg. the DYLD_PRINT_TO_FILE bug). Not really surprising since it's overwhelmingly used in practice as a single-user system.
- kentonv 10y ago
  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.
  - r3w 10y ago
    * don't let network services mmap (or even open!) random executables through mandatory access control (SELinux)
  - AstralStorm 10y ago
    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 10y ago
      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 10y ago
        No, it requires only two threads to trigger the race. Two processes are not needed.
        kentonv 10y ago
        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
deleted 10y ago
[deleted]
tptacek 10y ago
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 10y ago
  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.
  - Senji 10y ago
    If you are a client of such a busines you would have to care too.
    - qwertyuiop924 10y ago
      Of course you care about this sort of flaw: you need as many lines of defense as possible. But if anybody can exploit it in the first place, you've already got a major security hole.
  - throwaway2048 10y ago
    no, because a bug like this turns any code execution exploit into remote root...
    - tptacek 10y ago
      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.
saidajigumi 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      We live in a world where slightly arcane developer jokes are "SWAG squatted"
  - pmoriarty 10y ago
    Whenever I see something being sold for outrageous amounts of money (like some book on Amazon which can be bought new for $40, but some people are selling used for $1400) my first suspicion is: money laundering.
  - aji 10y ago
    it's definitely a joke. everything in the store is overpriced, FAQ item "how can I uninstall linux" links to a video of a guy smashing a computer, etc. look at this FAQ item: What's with the stupid (logo|website|twitter|github account)? It would have been fantastic to eschew this ridiculousness, because we all make fun of branded vulnerabilities too, but this was not the right time to make that stand. So we created a website, an online shop, a twitter account, and used a logo that a professional designer created. I think the author is just snarking about either branded vulnerabilities or the hype that this issue is getting. or both?
the_duke 10y ago
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.
- aexaey 10y ago
  And for earlier kernel versions, there is an STAP patch: 1) On the host, save the following in a file with the ".stp" extension: probe kernel.function("mem_write").call ? { $count = 0 } probe syscall.ptrace { // includes compat ptrace as well $request = 0xfff } 2) Install the "systemtap" package and any required dependencies. Refer to the "2. Using SystemTap" chapter in the Red Hat Enterprise Linux "SystemTap Beginners Guide" document, available from docs.redhat.com, for information on installing the required -debuginfo packages. 3) Run the "stap -g [filename-from-step-1].stp" command as root. From https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13 https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13
  - geofft 10y ago
    Doesn't this break Upstart (which uses ptrace for service activation), meaning you really don't want to use it on RHEL 6 or Ubuntu 14.04?
pbhjpbhj 10y ago
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 10y ago
  Yes, that is exactly what a privilege escalation bug is.
winter_blue 10y ago
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 10y ago
  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-2016-5195.html http://people.canonical.com/~ubuntu-security/cve/2016/CVE-20...
  - winter_blue 10y ago
    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_Kernel_Support https://wiki.ubuntu.com/Kernel/Support#A14.04.x_Ubuntu_Kerne... It's strange that my Kubuntu installation is frozen on 3.13.x.
    - Florin_Andrei 10y ago
ontoillogical 10y ago
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!
- JonRB 10y ago
  That sounds like an awesome idea - and a good way of promoting yourselves! I'll admit I spent a bit of time on your homepage thinking "the use of those birds are a bit twitter". Then I realised you're called App Canary.
- orblivion 10y ago
  It's sad that security information and news is so confusing as it is, but thank you for trying to improve it. I'll try to remember your site.
  - stass 10y ago
    Some operating systems like FreeBSD and (I think) Debian have this functionality built in without the need for external service. So it depends on what you are using. RedHat had a similar functionality as well AFAIR.
    - cyphar 10y ago
      SUSE-based distros have it as well (zypper tells you about CVE patches and how severe they are).
- rkv 10y ago
  Please do! Great work.
- ndesaulniers 10y ago
kordless 10y ago
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-8 https://www.google.com/search?q=f33ea7f404e5&ie=utf-8&oe=utf...
- antocv 10y ago
  You said it mon, "curious".
- i336_ 10y ago
  It is now, I see 16 results.
cm3 10y ago
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 10y ago
  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?
Hello71 10y ago
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.
- lima 10y ago
  Spender himself said that Grsecurity doesn't help with that one. Maybe it breaks that particular proof of concept.
- i336_ 10y ago
  I think the "it" you refer to here would be interesting to quite a few people, I'm having a hard time finding it.
- coldpie 10y ago
  How much is "quite some time"? It ran for several minutes before eventually succeeding on my fast, modern desktop.
  - Hello71 10y ago
    The loops finished.
- amscanne 10y ago
  Not sure if the race can be triggered with a single CPU.
100ideas 10y ago
Go go armlinux Internet of Things bot army!
ndesaulniers 10y ago
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.
drieddust 10y ago
>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.minix/wlhw16QWltI https://groups.google.com/forum/m/?fromgroups#!topic/comp.os...
- kentonv 10y ago
  Looks like you are quoting from: http://arstechnica.com/security/2016/09/linux-kernel-security-needs-fixing/ http://arstechnica.com/security/2016/09/linux-kernel-securit... 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.
  - wbl 10y ago
    seL4 does not have these kinds of errors. By shrinking the TCB, you make it possible to do hardcore verification. The challenge is in extending to larger systems and composition.
    - snvzz 10y ago
      Worth noting that as of Genode's latest release, a lot of progress has been made in that regard.
  - drieddust 10y ago
    Yeah not sure what happened. Somehow I ended up looking at wrong article. I am not very good at theory of Operating Systems but since Memory Management is separated from kernel it would have been difficult for a memory bug to impact other subsystems. Another argument is modularity which would have allowed better testing hence lesser chances of bugs.
fulafel 10y ago
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 10y ago
  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 10y ago
    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?).
cheiVia0 10y ago
Cool, this will be great for rooting Android phones to fix this and other security bugs!
- joelthelion 10y ago
  It's sad that anyone should have to rely on security bugs to take ownership of their own phone...
  - biafra 10y ago
    These phones exist, because people are buying them. Other phones that allow unlocking the bootloader also exist.
frederikvs 10y ago
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/VulnerabilityDetails https://github.com/dirtycow/dirtycow.github.io/wiki/Vulnerab...
- CUViper 10y ago
  See the SELinux boolean "deny_ptrace", and/or the sysctl "kernel.yama.ptrace_scope", and have at it. It's not just for debugging, but for any tool that needs some measure of process control. Probably the next most common ptrace-caller I know is "strace".
- aexaey 10y ago
  There are a surprising number of users for ptrace. E.g. upstart uses it to count forks (presumably to mitigate fork bombs), as geofft has pointed out above.
- dllthomas 10y ago
  > 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.
deleted 10y ago
[deleted]
escapologybb 10y ago
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!
AznHisoka 10y ago
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.
Unklejoe 10y ago
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.

483 points by saidajigumi 10y ago

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"

geofft 10y ago
Does this actually allow modifying the binary on disk, or just modifying the in-memory cached page? (i.e., is this a persistent attack that survives a reboot?)
- startling 10y ago
  It's just the in-memory executable, as I understand it.
anc84 10y ago
How does having /usr on a seperate partition (if I understood you correctly) change the bug/exploit?
- aexaey 10y ago
  Good point, edited to clarify.
qwertyuiop924 10y ago
Man, MADV_DONTNEED again? I mean, Linux's implementation is already weird (it behaves in a way counter to most other implementations of the call: you can see Bryan Cantrill's talk for the details). What is with that call?
- SysArchitect 10y ago
  Found the lightning talk: https://youtu.be/bg6-LVCHmGM?t=3521 https://youtu.be/bg6-LVCHmGM?t=3521
  - xzion 10y ago
    Looking forward to a followup talk of him gloating now this bug has been reported
    - qwertyuiop924 10y ago
      I genuinely doubt he'll notice. Bryan, if you're reading this, it's merely because I doubt that you actually check Linux bugtrackers. Also, GNU tail provides tail -F, which does what you want tail -f to do. There is a reason for this. I don't remember what it is, but I think the manpage talks about it.
      - i336_ 10y ago
        -F vs -f: -F figures out the new inode if the file is deleted (*notify are inode-based, if you see DELETE_SELF for a file you'll never get any more events)
        qwertyuiop924 10y ago
        ...which actually does handle truncation properly. For some reason.
        JdeBP 10y ago
        It's because IN_MODIFY covers both writing and truncation, so the code path for such an event has to handle both anyway. Ironically, given that you mention M. Cantrill, GNU tail does not really handle truncation properly, and gives up for almost the very case that M. Cantrill did: when the truncation doesn't decrease the size, or is very closely followed by a write that ends up not decreasing the size. Of course, truncation is not the best way to organize writing log files in the first place. daemontools family style log management (in cyclog, multilog, et al.) starts a fresh file whenever there is a rotation, so these problems of truncation never arise.
Florin_Andrei 10y ago
How does mounting the partition read-only help with modifying binary images in memory?
startling 10y ago
This exploit doesn't write to disk at all. It's about modifying the in-memory datastructures that correspond to executables on disk in between when they're read and executed.
DSMan195276 10y ago
I don't think that prevents this error. This exploit is all about gaining read-write access to a read-only page of memory. Mounting as read-only Might prevent the error, but only through extra checks of the dirty bit before pages are used (IE. The kernel would have to check the dirty bit on every page of a read-only file to ensure the contents were not changed through an exploit). The state of the disk and mounting of the disk generally wouldn't matter because the page is already being forced from read to read/write, and that has no barring on the mounting of or data on the actual disk. It doesn't matter if this data is actually flushed to the disk as long as the kernel uses it from cache without noticing it has been changed (Which it probably doesn't check regardless of read-only status).
mjg59 10y ago
Sadly, none of the security work we're doing would have helped in this case.
peterwwillis 10y ago
Fwiw, you should never think about an OS in terms of what security features they have enabled by default. The OS is almost always designed to help the user use programs and to help programs run. Just assume it is not secure until you do an audit + lockdown yourself. If you want a secure system by default, you should probably not use Linux. I would go with OSX or OpenBSD to start. (And finally: mounting /usr read-only isn't actually a security feature, because if you can exec code you can run a privesc and remount /usr read-write; mounting as noexec could arguably be considered a security feature)
- ams6110 10y ago
  OSX? How is that more secure by default than Linux?
  - peterwwillis 10y ago
    Less published exploits. Okay, so "more secure" isn't exactly correct, maybe "more difficult for a 10 year old with Metasploit to own it"
    - vacri 10y ago
      Who'd've thought that an OS that is rarely used to serve remote content is more resilient against software focused on breaking into remote systems?
- caf 10y ago
  OSX, really? It's had more than one privilege escalation exploitable from just a shell prompt (eg. the DYLD_PRINT_TO_FILE bug). Not really surprising since it's overwhelmingly used in practice as a single-user system.
kentonv 10y ago
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.
- r3w 10y ago
  * don't let network services mmap (or even open!) random executables through mandatory access control (SELinux)
- AstralStorm 10y ago
  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 10y ago
    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 10y ago
      No, it requires only two threads to trigger the race. Two processes are not needed.
      - kentonv 10y ago
        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

deleted 10y ago

[deleted]

tptacek 10y ago

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 10y ago
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.
- Senji 10y ago
  If you are a client of such a busines you would have to care too.
  - qwertyuiop924 10y ago
    Of course you care about this sort of flaw: you need as many lines of defense as possible. But if anybody can exploit it in the first place, you've already got a major security hole.
- throwaway2048 10y ago
  no, because a bug like this turns any code execution exploit into remote root...
  - tptacek 10y ago
    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.

saidajigumi 10y ago

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 10y ago
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 10y ago
  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 10y ago
    We live in a world where slightly arcane developer jokes are "SWAG squatted"
- pmoriarty 10y ago
  Whenever I see something being sold for outrageous amounts of money (like some book on Amazon which can be bought new for $40, but some people are selling used for $1400) my first suspicion is: money laundering.
- aji 10y ago
  it's definitely a joke. everything in the store is overpriced, FAQ item "how can I uninstall linux" links to a video of a guy smashing a computer, etc. look at this FAQ item: What's with the stupid (logo|website|twitter|github account)? It would have been fantastic to eschew this ridiculousness, because we all make fun of branded vulnerabilities too, but this was not the right time to make that stand. So we created a website, an online shop, a twitter account, and used a logo that a professional designer created. I think the author is just snarking about either branded vulnerabilities or the hype that this issue is getting. or both?

the_duke 10y ago

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.

aexaey 10y ago
And for earlier kernel versions, there is an STAP patch: 1) On the host, save the following in a file with the ".stp" extension: probe kernel.function("mem_write").call ? { $count = 0 } probe syscall.ptrace { // includes compat ptrace as well $request = 0xfff } 2) Install the "systemtap" package and any required dependencies. Refer to the "2. Using SystemTap" chapter in the Red Hat Enterprise Linux "SystemTap Beginners Guide" document, available from docs.redhat.com, for information on installing the required -debuginfo packages. 3) Run the "stap -g [filename-from-step-1].stp" command as root. From https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13 https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13
- geofft 10y ago
  Doesn't this break Upstart (which uses ptrace for service activation), meaning you really don't want to use it on RHEL 6 or Ubuntu 14.04?

pbhjpbhj 10y ago

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 10y ago
Yes, that is exactly what a privilege escalation bug is.

winter_blue 10y ago

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 10y ago
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-2016-5195.html http://people.canonical.com/~ubuntu-security/cve/2016/CVE-20...
- winter_blue 10y ago
  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_Kernel_Support https://wiki.ubuntu.com/Kernel/Support#A14.04.x_Ubuntu_Kerne... It's strange that my Kubuntu installation is frozen on 3.13.x.
  - Florin_Andrei 10y ago

ontoillogical 10y ago

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!

JonRB 10y ago
That sounds like an awesome idea - and a good way of promoting yourselves! I'll admit I spent a bit of time on your homepage thinking "the use of those birds are a bit twitter". Then I realised you're called App Canary.
orblivion 10y ago
It's sad that security information and news is so confusing as it is, but thank you for trying to improve it. I'll try to remember your site.
- stass 10y ago
  Some operating systems like FreeBSD and (I think) Debian have this functionality built in without the need for external service. So it depends on what you are using. RedHat had a similar functionality as well AFAIR.
  - cyphar 10y ago
    SUSE-based distros have it as well (zypper tells you about CVE patches and how severe they are).
rkv 10y ago
Please do! Great work.
ndesaulniers 10y ago

kordless 10y ago

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-8 https://www.google.com/search?q=f33ea7f404e5&ie=utf-8&oe=utf...

antocv 10y ago
You said it mon, "curious".
i336_ 10y ago
It is now, I see 16 results.

cm3 10y ago

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 10y ago
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?

Hello71 10y ago

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.

lima 10y ago
Spender himself said that Grsecurity doesn't help with that one. Maybe it breaks that particular proof of concept.
i336_ 10y ago
I think the "it" you refer to here would be interesting to quite a few people, I'm having a hard time finding it.
coldpie 10y ago
How much is "quite some time"? It ran for several minutes before eventually succeeding on my fast, modern desktop.
- Hello71 10y ago
  The loops finished.
amscanne 10y ago
Not sure if the race can be triggered with a single CPU.

100ideas 10y ago

Go go armlinux Internet of Things bot army!

ndesaulniers 10y ago

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.

drieddust 10y ago

>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.minix/wlhw16QWltI https://groups.google.com/forum/m/?fromgroups#!topic/comp.os...

kentonv 10y ago
Looks like you are quoting from: http://arstechnica.com/security/2016/09/linux-kernel-security-needs-fixing/ http://arstechnica.com/security/2016/09/linux-kernel-securit... 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.
- wbl 10y ago
  seL4 does not have these kinds of errors. By shrinking the TCB, you make it possible to do hardcore verification. The challenge is in extending to larger systems and composition.
  - snvzz 10y ago
    Worth noting that as of Genode's latest release, a lot of progress has been made in that regard.
- drieddust 10y ago
  Yeah not sure what happened. Somehow I ended up looking at wrong article. I am not very good at theory of Operating Systems but since Memory Management is separated from kernel it would have been difficult for a memory bug to impact other subsystems. Another argument is modularity which would have allowed better testing hence lesser chances of bugs.

fulafel 10y ago

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 10y ago
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 10y ago
  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?).

cheiVia0 10y ago

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

joelthelion 10y ago
It's sad that anyone should have to rely on security bugs to take ownership of their own phone...
- biafra 10y ago
  These phones exist, because people are buying them. Other phones that allow unlocking the bootloader also exist.

frederikvs 10y ago

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/VulnerabilityDetails https://github.com/dirtycow/dirtycow.github.io/wiki/Vulnerab...

CUViper 10y ago
See the SELinux boolean "deny_ptrace", and/or the sysctl "kernel.yama.ptrace_scope", and have at it. It's not just for debugging, but for any tool that needs some measure of process control. Probably the next most common ptrace-caller I know is "strace".
aexaey 10y ago
There are a surprising number of users for ptrace. E.g. upstart uses it to count forks (presumably to mitigate fork bombs), as geofft has pointed out above.
dllthomas 10y ago
> 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.

deleted 10y ago

[deleted]

escapologybb 10y ago

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!

AznHisoka 10y ago

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.

Unklejoe 10y ago

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.