6 ms·
CVE-2016-5195 This flaw allows an attacker with a local system account to modify on-disk binaries, bypassing the standard permission mechanisms that woul
by 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 agoDoes 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 agoIt's just the in-memory executable, as I understand it.
- anc84 10y agoHow does having /usr on a seperate partition (if I understood you correctly) change the bug/exploit?
- aexaey 10y agoGood point, edited to clarify.
- qwertyuiop924 10y agoMan, 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 agoFound the lightning talk: https://youtu.be/bg6-LVCHmGM?t=3521 https://youtu.be/bg6-LVCHmGM?t=3521
- xzion 10y agoLooking forward to a followup talk of him gloating now this bug has been reported
- qwertyuiop924 10y agoI 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 agoIt'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 agoHow does mounting the partition read-only help with modifying binary images in memory?
- startling 10y agoThis 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 agoI 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 agoSadly, none of the security work we're doing would have helped in this case.
- peterwwillis 10y agoFwiw, 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 agoOSX? How is that more secure by default than Linux?
- peterwwillis 10y agoLess 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 agoWho'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 agoOSX, 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 agoAs 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 agoPtrace 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 agoNo, 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 agoNo, it requires only two threads to trigger the race. Two processes are not needed.
- kentonv 10y agohttps://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