Slashdot Mirror
Bug In Most Linuxes Can Give Untrusted Users Root
Red Midnight and other readers brought to our attention a bug in most deployed versions of Linux that could result in untrusted users getting root access. The bug was found by Brad Spengler last month. "The null pointer dereference flaw was only fixed in the upcoming 2.6.32 release candidate of the Linux kernel, making virtually all production versions in use at the moment vulnerable. While attacks can be prevented by implementing a common feature known as mmap_min_addr, the RHEL distribution... doesn't properly implement that protection... The... bug is mitigated by default on most Linux distributions, thanks to their correct implementation of the mmap_min_addr feature. ... [Spengler] said many other Linux users are also vulnerable because they run older versions or are forced to turn off [mmap_min_addr] to run certain types of applications." The register reprints a dialog from the OpenBSD-misc mailing list in which Theo De Raadt says, "For the record, this particular problem was resolved in OpenBSD a while back, in 2008. We are not super proud of the solution, but it is what seems best faced with a stupid Intel architectural choice. However, it seems that everyone else is slowly coming around to the same solution."
But you don't know if I didn't just hack the servers ;)
For those who just want to know how to fix it, you need to apply this git commit to your kernel tree and then either recompile and reboot or apply the patch using ksplice.
Nope, it is a new one, but the same old bugfix still works.
Just type sysctl -w vm.mmap_min_addr=4096 in your box (or any other number > 0) and you are safe.
I'm not a real security guy, but my experiences with security bug reporting shows that nearly all such subtle bugs are pooh-poohed by the original authors till the exploit writer resorts to petulant scaremongering. I'm not sure which one is to blame for either one's behaviour.
All of these attacks IIRC require you to be able to mmap() page zero. Which is why mmap_min_addr is almost never set low enough in a decently protected OS. But the fact is that the exploit is a valid bug for a system which hasn't got that set to 4k. And there is a valid root exploit using pulseaudio (*ouch*) as a vector.
Linus might have been right in saying setuid is a 'vulnerability', but to call it a design flaw is wrong. Setuid is not a design flaw, it is a trade-off - needed for something as simple as 'ping' to function (yeah, ping's got setuid, check it).
Being able to exploit a setuid binary after mmap'ing page zero with executable shell code, via a phpbb vulnerability which is exposed because of lack of php filtering is like saying ... "look, having arranged these six dominoes, I only need to push *one* over".
I'm not denying either of them aren't right in their own way - but invariably original author vs security researcher sets up a very immature exchange of insults (and the ego of both types don't help either).
Quidquid latine dictum sit, altum videtur
Torvalds:
Am I missing something? Torvald's reply actually sounds pretty reasonable to me here. It might be nice if this exploit could be patched, but it seems a little preposterous to me that you could make that work in a way that doesn't leave an exploit. I'd say you need to be locking down your suid binaries more, not blaming kernel management.
I thought Masturbating Monkey was Ubuntu 10.10?
I read Theo's comments and he's going on an on about Torvald's fixation with masturbating monkeys. Then some member of the openBSD crowd even offers a link to purchasing "your very own" **masturbating monkey** http://www.wellcoolstuff.com/Merchant2/graphics/00000001/20-Apr-07-05.jpg
Then I read Torvald's comment about the Linux exploit, with Torvald referring to the openBSD developers as being __like__ a "bunch of masturbating monkeys".
Ok, so is this like some kind of secret code used among OS kernel developers? Like saying "my shoe is blue but the cow is hungry" really means "Oh man, this code is leaking memory and crashing my system"? Or is this some kind of secret initiation thing, where in order to truly become a member of the OS development club, you have to first ... masturbate a monkey??!! Can somebody explain it, or maybe do some investigative reporting on this?
No, this isn't the same bug. People confuse two issues. I wrote the mmap_min_addr protections to try to mitigate the effects of a certain class of common kernel bugs which exist because of design choices by Intel. That class of bugs can be summed up as NULL pointer usage. Every time someone finds a new NULL pointer usage bug we get the same story. RHEL (and any system with SELinux enabled) did not have protections for mapping the 0 page by local authenticated users, but did have protections for network facing daemons and the like. Other distros had protections for the local authenticated user but weaker protections for network facing daemons. The mmap_min_addr protections have since been enhanced in SELinux systems such that they have stronger protections, both for local authenticated users and for network facing daemons. My old comments from the first time this came up are at http://eparis.livejournal.com/
But the key to remember is that mmap_min_addr implementation is not the bug that allows elevation of privilege. In this case it was a very very old bug in the implementation of pipes. Previously Spender and friends have found bugs in performance counters (one which was actually much worse as it didn't fit into the very narrow class which might be mitigated by mmap_min_addr), in network sockets, and other places. These are the bugs which cause this to be a new story. Once he finds the real bugs he applies some of the same basic techniques (plus a whole lot of thought) to create an exploit. If the Linux kernel was bug free we wouldn't need mmap_min_addr. If mmap_min_addr was bug free (over the years Spender has found multiple problems with my work) this class of bugs would be just a bit less devastating.
Everyone in the kernel development community needs to think of invalid pointer bugs as a larger security threat then they currently do. The lesson here, keep your systems patched.
A patched kernel will fix this particular bug, but as long as wine is installed and mmap_min_addr is being set to 0 you have no protections for the next bug. Unless wine can be changed (which some smart people have told me it can't), there's nothing you can do except accept a higher security risk on your system.
Here's a fun tag line, "Windows applications can even make Linux less secure!"
So it's a windows bug.
My understand in a short and simple answer: before the x86_64 architecture revolution it was possible to effectively have a separate virtual memory space for the kernel and userspace. With x86_64 segmentation was removed.
Intel i686 processors had a pretty big performance hit if you used functionality since there was a TLB flush on every kernel trap. I don't believe many kernels made use of it. The PaX security patch set could and Red Hat's 4g/4g split kernels did (RH called them hugemem kernels, although I don't suggest them to anyone as they had their own issues.) The AMD Opteron processors actually had tagged TLBs so they didn't have to flush and performance didn't suffer nearly as badly.
In any case, with x86_64 that ability is simply gone. SPARC is often named as an architecture which doesn't suffer from this specific class of bugs since it always had completely separate kernel space and userspace virtual memory. I heard rumour their might be a brilliant solution that will hopefully come from the PaX/grsecurity team, but I don't believe anything has materialized just yet.