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

Comments

First post

[wisty]

But you don't know if I didn't just hack the servers ;)

standard author/exploiter response?

[Gopal.V]

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

Re:standard author/exploiter response?

[Late Adopter]

The only way to remove the setuid requirement from ping (apart from making your system thoroughly insecure) is to allow messages to be sent and received on raw sockets opened by non-root only if they're ICMP ECHO messages (I'm not aware of any other ICMP messages that it's useful for user code to send).

That's absolutely not the only way. You can make raw sockets accessible via a node in /dev, which you can assign to a group, control membership in, and setuid/setgid a NON-root user to "ping".

A *lot* of system resources are controlled in this manner (dri, sound, disks). I still don't think it's a sufficiently versatile security model (cf my comment on sandboxing), but it's a good place to start.

Re:obvious troll is obvious.

[blueskies]

OS persons would be jumping about like grass-hoppers that THIS could never happen in OS software...The Many Eyes theory looks weak...

You misunderstand then. It's not the point that it could never happen, but that it gets found and fixed. This bug was found in the absence of proof of concept code unlike the reverse situation.

Re:I'd rather pay $400 for bugs likes this

[MikeBabcock]

Lets compare apples to apples. Lets say you have an out-of-maintenance version of Linux (which would be some of the intermediate releases not in use by major distros) and your distro won't be patching you. You have the option of paying someone a lot less than $400 to back-port this patch to your kernel version or doing it yourself.

Now lets say you have an unsupported version of Windows (like NT 3.51) and you find out there's a major security hole in Vista dating right back to 3.51. How are you going to get that fixed? If you answer "by upgrading" then use the same answer with Linux.

The whole point of FOSS is that you're never stuck, you can always just do it yourself or pay someone to do it for you, the vendor can't lock you out of the code running on your systems.

Of course, if you run a maintained version of any Enterprise Linux I'd put good bets down that they'll be patched shortly. If you spun your own distro, then you made the choice to maintain it yourself anyway.