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

21–30 of 218 posts

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

#21

Post by startling »

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…

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

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

#22

Post by startling »

geofft wrote: post #5
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…

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

It's just the in-memory executable, as I understand it.

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

#23

Post by startling »

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…

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.

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

#24

Post by tptacek »

startling wrote: post #21
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…

> "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 a system where I knew I had to burn the box if I lost RCE on it than I would be with a system that somehow depended on RCE not coughing up kernel, and persistence, to an attacker.

The other thing defense in depth can provide is increased attacker cost. That's why there are economically valuable DRM systems (BluRay's BD+ is an example here). All you have to do is push attacker cost across a threshold (for instance with BD+, that's keeping titles secure past the new release window) to make a defense in depth control valuable.

But if someone has a kernel exploit, probably nothing you've done for defense in depth is going to meaningfully increase costs.

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

#25

Post by qwertyuiop924 »

Senji wrote: post #19
qwertyuiop924 wrote: post #8

Earlier quoted context omitted.

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.

If you are a client of such a busines you would have to care too.

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.

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

#26

Post by nine_k »

rodgerd wrote: post #18
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…

> that was then undone due to problems on s390 An interesting counter-example to the idea that "more architectures expose problems that would hide in a monoculture".

Expose, not solve.

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

#27

Post by hueving »

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.

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

#28

Post by qwertyuiop924 »

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…

> That's why there are economically valuable DRM systems (BluRay's BD+ is an example here). All you have to do is push attacker cost across a threshold (for instance with BD+, that's keeping titles secure past the new release window) to make a defense in depth control valuable.

A really good example of this is Spyro 3: The developers set up a system of overlapping checksums (which could in turn bet part of the data being checksummed by other, overlapping, checksums) so that it was virtually impossible to change even a single bit without failing the test. It was eventually cracked, as the check only ran at boot time (it required 10 seconds of disk access, and adding 10 seconds to every loading screen in the game would have been unacceptable), which meant it took over two months for pirates to get a crack working (unusual for the time). And since most game sales come in the first two months...

But that's really just me using this as an excuse to share a bit of technical trivia.

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

#29

Post by qwertyuiop924 »

tcoppi wrote: post #16
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…

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

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

#30

Post by Diederich »

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.

Citation needed.

That's certainly a goal, but I've never heard the claim.

Post reply on HN