See also the dedicated page for this vulnerability, dubbed Dirty COW (for copy-on-write), aka CVE-2016-5195: http://dirtycow.ninja/
I was actually happy to see that the submitted link didn't point to the "marketing site" for the vulnerability.
“Most serious” Linux privilege-escalation bug ever is under active exploit
111–120 of 218 posts
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#112Earlier quoted context omitted.
It seems like both SELinux and AppArmor could be configured to block access to /proc/self/mem which should mitigate it.
It's sad actually that this is the perfect type of exploit to block with SElinux, a simple write to unauthorized files. But since no one uses the user contexts of selinux then no one blocks this. Your shell runs unconfined because your user role is unconfined. Any process you might start will therefore run unconfined, unless stated otherwise in a policy. So this exploit will run unconfined and will be allowed writes…
> Your shell runs unconfined because your user role is unconfined. Any process you might start will therefore run unconfined, unless stated otherwise in a policy.
I am actually surprised that sane and safe defaults are ignored and left to user's discretion. Most users think Linux is secure by default.
It's interesting to see Windows going into other direction and locking down more and more by default.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#113Seems to be fixed by this commit (in 4.8.3). commit 89eeba1594ac641a30b91942961e80fae978f839 Author: Linus Torvalds 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() ra…
[deleted]
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#114>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...
Looks like you are quoting from: 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.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#115CVE-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) rea…
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.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#116Earlier quoted context omitted.
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.
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 reproducib…
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.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#117Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#118Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#119Seems to be fixed by this commit (in 4.8.3). commit 89eeba1594ac641a30b91942961e80fae978f839 Author: Linus Torvalds 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() ra…
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 Beginne…
Nope, this only helps against one particular exploit which happens to use ptrace and /proc/self/mem.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#120Doesn'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.
Spender himself said that Grsecurity doesn't help with that one. Maybe it breaks that particular proof of concept.