Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

31–40 of 218 posts

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

#31

Post by DSMan195276 »

aexaey wrote: post #2

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) rea…

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

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

#32

Post by geofft »

aexaey wrote: post #12
the_duke wrote: post #7

Seems 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…

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?

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

#33

Post by mjg59 »

hueving wrote: post #27
tptacek wrote: post #4

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 rig…

>assume that code execution on your Linux systems equates to privesc Tell this to the container community. They would have you believe containers are as secure as VMs.

Given qemu's security track record, they're not necessarily wrong.

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

#34

Post by mjg59 »

aexaey wrote: post #2

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) rea…

Sadly, none of the security work we're doing would have helped in this case.

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

#35

Post by School-Cotton »

qwertyuiop924 wrote: post #29
tcoppi wrote: post #16

Earlier quoted context omitted.

> 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. I think this goes for any mainstream OS, Linux is not particularly special here.

Assume it on any system. Even OpenBSD. Nobody's perfect. Not even Theo.

> FreeBSD

> Theo

Do you mean OpenBSD ?

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

#36

Post by ryuuchin »

tptacek wrote: post #4

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 rig…

Well another thing to keep in mind with this one in particular is that there is no way to mitigate it. grsecurity can't help with this kind of bug, nothing can so it may not just be about reliability of this exploit but the fact that there's no mitigation other than to update.

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

#37

Post by qwertyuiop924 »

School-Cotton wrote: post #35
qwertyuiop924 wrote: post #29

Earlier quoted context omitted.

Assume it on any system. Even OpenBSD. Nobody's perfect. Not even Theo.

> FreeBSD > Theo Do you mean OpenBSD ?

Why yes, yes I did. Thanks for pointing that out.

Edited to fix.

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

#38

Post by xzion »

SysArchitect wrote: post #14
qwertyuiop924 wrote: post #11

Earlier quoted context omitted.

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?

Found the lightning talk: https://youtu.be/bg6-LVCHmGM?t=3521

Looking forward to a followup talk of him gloating now this bug has been reported

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

#39

Post by pmoriarty »

vesinisa wrote: post #15
saidajigumi wrote: post #6

See also the dedicated page for this vulnerability, dubbed Dirty COW (for copy-on-write), aka CVE-2016-5195: http://dirtycow.ninja/

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?)

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.

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

#40

Post by timtadh »

tptacek wrote: post #24
startling wrote: post #21

Earlier quoted context omitted.

> "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. It depends. I've seen "oh well if someone has rce they probably have root anyway" used way too many times as an excuse to avoid defense-in-depth measures.

Those people might be right. Defense in depth is a legitimate tactic, but that's all it is, and it's often an excuse for people to waste time layering stupid stuff on top of real security controls. ASLR, NX, and CFI would be an example of a defense in depth stack that is meaningful. SSH, Fail2Ban, and SPA would be an example of a defense in depth stack that basically just wastes time. I would be more comfortable with…

I'm confused, how is SSH an example of defense in depth? It is an access method. You should absolutely harden your SSH configuration. Fail2Ban is useless on a properly configured SSH server (no root, no passwords, no kerberos, only keys). Managing the keys at scale, well that is a different story.

I agree with you that ASLR, NX, and CFI are the most important system level defenses to employ.

Post reply on HN