Hacker News Reader

Comment by aexaey | Hacker News Reader

  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"

View on HN

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

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

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

...which actually does handle truncation properly. For some reason.

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

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.

Naturally. This is quite sensible.

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

I don't think you need madvise() for this bug. It's just easier to exploit that way.

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.

* don't let network services mmap (or even open!) random executables through mandatory access control (SELinux)

Ptrace is not needed for an exploit, you only need to be able to mmap a file. Does not even have to be writable.

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

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.

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

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

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.

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

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

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.

How does mounting the partition read-only help with modifying binary images in memory?

How does having /usr on a seperate partition (if I understood you correctly) change the bug/exploit?

Good point, edited to clarify.

Fwiw, 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)

OSX? How is that more secure by default than Linux?

Less published exploits. Okay, so "more secure" isn't exactly correct, maybe "more difficult for a 10 year old with Metasploit to own it"

Who'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?

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

Reply on news.ycombinator.com