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

211–218 of 218 posts

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

#211

Post by kentonv »

amscanne wrote: post #204
kentonv wrote: post #199

Earlier quoted context omitted.

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.

No, it requires only two threads to trigger the race. Two processes are not needed.

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

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

#212

Post by Karunamon »

digi_owl wrote: post #174
AsyncAwait wrote: post #165

Earlier quoted context omitted.

The link doesn't say what you say it does. It says that Linus thinks that security researchers want to put security at the expense of usability, which is a different thing entirely.

That, and that a bug is a bug is a bug. Any bug can potentially be a security vulnerability with the right approach. Thus putting people that find such bugs on a pedestal is counterproductive.

A bug that makes your graphics flicker is not equivalent in severity or seriousness to one that lets third parties execute code on your computer.

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

#213

Post by kentonv »

ifhs wrote: post #202
kentonv wrote: post #115

Earlier quoted context omitted.

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…

Yup, you guys reinvented docker

We had this sandboxing ~2 years before Docker did, so apparently Docker reinvented Sandstorm?

(They're actually completely different products.)

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

#214

Post by zAy0LfpBZLC8mAC »

Karunamon wrote: post #212
digi_owl wrote: post #174

Earlier quoted context omitted.

That, and that a bug is a bug is a bug. Any bug can potentially be a security vulnerability with the right approach. Thus putting people that find such bugs on a pedestal is counterproductive.

A bug that makes your graphics flicker is not equivalent in severity or seriousness to one that lets third parties execute code on your computer.

How did you prove that it's not also a security problem? Experience shows that there are often surprising ways to abuse what seems to be a benign bug to break security of a system.

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

#215

Post by JdeBP »

qwertyuiop924 wrote: post #198
JdeBP wrote: post #197

Earlier quoted context omitted.

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, tru…

What I was actually referring to was Cantrill's talk about tail -f on Solaris, and how he improved it (so that it at least handled some cases). He looked at the GNU behavior, and determined that truncation was noted, but nothing was done about it. This is true if you use -f. However, if you use -F, truncation is handled properly.

I know what you were referring to. It has already been hyperlinked; I had already referred to where M. Cantrill explained that he gave up; and as I have just explained, the people who wrote GNU tail gave up in the same way (for much the same reasons, I expect) and GNU tail does not handle truncation any more properly than M. Cantrill did. There's no doco, but there's commentary in the code observing the problem.

And as I then went on to explain, this whole idea of truncating one log file over and over is a poor one, and not the best way to do logging in the first place. So the fact that both M. Cantrill and the GNU people gave up should perhaps be viewed as stopping when an inferior mechanism is pushed beyond its limits.

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

#216

Post by qwertyuiop924 »

JdeBP wrote: post #215
qwertyuiop924 wrote: post #198

Earlier quoted context omitted.

What I was actually referring to was Cantrill's talk about tail -f on Solaris, and how he improved it (so that it at least handled some cases). He looked at the GNU behavior, and determined that truncation was noted, but nothing was done about it. This is true if you use -f. However, if you use -F, truncation is handled properly.

I know what you were referring to. It has already been hyperlinked; I had already referred to where M. Cantrill explained that he gave up; and as I have just explained, the people who wrote GNU tail gave up in the same way (for much the same reasons, I expect) and GNU tail does not handle truncation any more properly than M. Cantrill did. There's no doco, but there's commentary in the code observing the problem. And…

Naturally. This is quite sensible.

The ambiguities of language sometimes make two people with the same idea think their ideas are different.

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

#217

Post by kentonv »

kentonv wrote: post #211
amscanne wrote: post #204

Earlier quoted context omitted.

No, it requires only two threads to trigger the race. Two processes are not needed.

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 /pr…

I just talked to amluto who explained that the race can only be triggered by a write that uses the "force" flag to get_user_pages() (a kernel function). /proc/pid/mem and ptrace() do this but regular writes and process_vm_writev() do not.

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

#218

Post by kentonv »

amscanne wrote: post #204
kentonv wrote: post #199

Earlier quoted context omitted.

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.

No, it requires only two threads to trigger the race. Two processes are not needed.

Update: We talked to Andy Lutomirski who was involved in reverse-engineering the original exploit and tracking down the bug. He says the code path is not triggered by regular memory writes; you have to go through ptrace() or /proc/self/mem. Details in this blog post:

https://sandstorm.io/news/2016-10-25-cve-2016-5195-dirtycow-...

Of course, if you have evidence to the contrary, we'd all like to know about it!

(You are technically correct that the writes can come from another thread rather than another process, but the important part is that it has to go through one of those interfaces.)

Post reply on HN