Bug In Most Linuxes Can Give Untrusted Users Root 281
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."
First post (Score:5, Insightful)
But you don't know if I didn't just hack the servers ;)
Isn't this a dupe? (Score:2, Insightful)
Surely this [slashdot.org] is the same story, from 2 months ago.
obvious troll is obvious. (Score:2, Insightful)
So, anti-Windows people? Whatcha say now? ;-)
Thank god that independent forces are out there finding and reporting kernel bugs in Linux. If only the bug-finders for windows were so altruistic.
standard author/exploiter response? (Score:5, Insightful)
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:obvious troll is obvious. (Score:4, Insightful)
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.
I'd rather pay $400 for bugs likes this (Score:3, Insightful)
And know the fix would be back-ported to Server 2003. How many "stable" kernel versions will the fix be back ported to? Will my 2.4.x kernels get a patch?
Re:I'd rather pay $400 for bugs likes this (Score:3, Insightful)
``Will my 2.4.x kernels get a patch?''
Are they vulnerable?
Re:Isn't this a dupe? (Score:3, Insightful)
Ran off my Ubuntu 9.10 fresh installed desktop:
#cat /proc/sys/vm/mmap_min_addr ... Oh shit.
0
Re:Same Exploit from July? (Score:3, Insightful)
Well, there's always MITRE Common Vulnerabilities and Exposures [mitre.org], which is a good pretty much dupe-free index of reported vulns. Most professional discussions of vulnerabilities tend to use CVE references.
For instance, this particular vuln looks like CVE 2009-2695 [mitre.org]. The one discussed in the July /. article appears to be CVE 2009-1897 [mitre.org].
The CVE pages are pretty good, complete with cross references to discussions and some pretty detailed analysis of the vulnerability.
Re:Somebody fill me in.. (Score:2, Insightful)
It never helps. (Even when he's right, which he always is when the discussion involves something technical.)
Fixed.
Re:standard author/exploiter response? (Score:2, Insightful)
You are aware that in order for ping to work at all, it needs raw sockets so that it can write ICMP packets? Those are restricted because they allow you to spoof all sorts of network traffic (e.g., the ethernet address to IP address mapping) Which Would Be Bad.
This seems less bad than kludgy workarounds.
Network services should never trust that the packets sent to it are not forged. Ever. Session-based authentication If the network services were written with this caveat in mind (which can never really be eliminated anyways, since there's no way of knowing whether the client app is mangling packets) then there would be no problem letting userland programs have access to raw sockets.
Re:standard author/exploiter response? (Score:4, Insightful)
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:So? (Score:3, Insightful)
Yup, randomly, anonymously taking your anger out on uninvolved bystanders is definitely the way to correct the system.
I guess it never occurred to you that you are doing the same thing that put you in your little temper tantrum to begin with.
Let's hope the people you target are more mature than you.
Re:standard author/exploiter response? (Score:1, Insightful)
Ah yes, thank you Wrath0fb0b for letting the network development community know that they were wrong all this time with their tradeoffs, as I'm sure your typical Slashdot basement remark has been clearly thought through. We could use more people than you!
Re:I'd rather pay $400 for bugs likes this (Score:5, Insightful)
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.