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 ;)
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.
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.
If the result is non-zero the vulnerability doesn't exist.
'Most deployed versions of linux'?.
So far only some unpatched RHEL versions allow this local exploit, even the Centos rip-off doesn't have it.
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.
It says that it was only fixed " in the upcoming 2.6.32 release candidate of the Linux kernel" - hence everything before that is vulnerable.
But the bug is not exploitable on ubuntu, because they set vm.mmap_min_addr > 0 by default.
Hah, this just shows how EFFICIENT Linux is. Until recently, Windows achieved their local privilege escalation vulnerability rollout by having almost every home user running as fully privileged administrator accounts all the time. Linux achieves all this through a small tweak to the kernel build system, thus getting this feature to 100% of Linux users without any manual intervention at all.
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.
You know you can click on the article links and actually read them.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
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.
Before people jump on Theo's comment, it's worth pointing out that it was Linus who first described the OpenBSD developers as "masturbating monkeys". That said, it's still bloody childish irrespective of who it's coming from.
It's not Linus and Theo, it's Theo and everybody.
And yes, it's dueling egos. Theo is a very good coder, and OpenBSD is an amazing system, but Theo should stop talking to the public. It never helps. (Even when he's right, which he usually is when the discussion involves something technical.)
'Sensible' is a curse word.
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?
This is from Fedora running kernel 2.6.30 with minimal customization (almost default, and no tweaking related to this one):
$ cat /proc/sys/vm/mmap_min_addr
65536
The devs seem to be doing an adequate job to mitigate this problem.
Colorless green Cthulhu waits dreaming furiously.
This solution works, please see the links below. However I would reccomend seing what your settings are on your system
$ sysctl -n vm.mmap_min_addr to find what your setting is.
On Ubuntu 8.04 LTS servers (including Xen kernels) and on 9.10 desktops it is 65536. Not a big deal.
http://wiki.debian.org/mmap_min_addr
https://lists.ubuntu.com/archives/ubuntu-devel/2008-July/025805.html
http://www.securityfocus.com/bid/26831/info
But the bug is not exploitable on ubuntu, because they set vm.mmap_min_addr > 0 by default.
That doesn't seem to be generally true.
Ubuntu Hardy 8.04 LTS, 2.6.24-25-generic: vm.mmap_min_addr = 65536; Ubuntu Jaunty 9.04, 2.6.28-16-generic: vm.mmap_min_addr = 0. So, by the above logic, Ubuntu Jaunty is vulnerable, although Hardy is safe.
Also seems like vm.mmap_min_addr = 0 for all the Debian boxes I can get my hands on...
(All my comments above relate to the stock/packaged kernels for the distribution)
"If you think the problem is bad now, just wait until we've solved it." --- Arthur Kasspe
Ran off my Ubuntu 9.10 fresh installed desktop:
#cat /proc/sys/vm/mmap_min_addr ... Oh shit.
0
Well, there's always MITRE Common Vulnerabilities and Exposures, 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. The one discussed in the July /. article appears to be CVE 2009-1897.
The CVE pages are pretty good, complete with cross references to discussions and some pretty detailed analysis of the vulnerability.
Welcome to the Panopticon. Used to be a prison, now it's your home.
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?
Ran off my Ubuntu 9.10 fresh installed desktop:
#cat /proc/sys/vm/mmap_min_addr
0 ... Oh shit.
Is it possible that you are running wine or some other emulator program. The only software similar to an emulator I have is Virtualbox on my 9.10 desktop and it still has the 65536 setting.
Anyone else can shed light 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.
I have VirtualBox and Wine, and VirtualBox uses a kernel module. So it's possible that one of those could have set it to 0. I set it to 65000 just in case and it didn't break Wine or VirtualBox...
Ubuntu sets this to zero if you have wine installed.
Might be feeding the toll but,
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.
Mod points: Guaranteed to remove your sense of humor.
Side effects may include gullibility and temporary retardation
So it's a windows bug.
What's the beef between Linus and Theo?
Theo is in charge of a BSD-based kernel that is only concerned with security, while Linus is in charge of a kernel that has to accommodate a much wider audience (like people who want to run Wine), and, of course, since both of them also have largish egos, they've both managed to say some silly things about each other's kernel...
Basically, unless you're already a Linus or Theo fanboy, their 'bickering' is not that important. :)
Just what design choice was made (wrong) by Intel, and why is it a bad choice?
now we need to go OSS in diesel cars
Not on 8.04 (the last LTS release). Any ideas why it would do that?
My blog. Good stuff (when I remember to update it). Read it.
Linus's comment:
"That does not look like a kernel problem to me at all. He's running a setuid program that allows the user to specify its own modules. And then you people are surprised he gets local root?"
Sounds reasonable to me.
Well, here's the thing... For the exploit to work you need either mmap_min_addr to be 0, or you need your process to have CAP_SYS_RAWIO. In other words, if you were running on a system that had mmap_min_addr set to 0, you could run this exploit without already having root authority. Wine needs this, apparently...
The workaround for mmap_min_addr (by exploiting dangerous SUID code in Pulse) was just icing on the cake.
Bow-ties are cool.
What do you mean Windows requires it to work like this? On Windows accessing a NULL pointer is always an exception, no process is ever allowed to map the bottom page of memory. This has been true since Windows has existed. So in fact it is only Windows systems that are immune to this class of exploit because writing programs and kernel code vulnerable to it leads to an immediate crash.
If you wanted to specify this invariant on Linux you could, you'd just break some existing apps that depend on it. Ironically, it seems that Wine depends on this behavior.
Natural != (nontoxic || beneficial)
Because Wine needs access to the bottom 64k of memory in order to run 16-bit DOS programs
I have two machines with Open SuSE 11.1 One returns 0, and the other 65535. The one returning zero runs only samba and apache (+webdav module for an ical server). The one returning 65535 runs samba and xen.
Just type sysctl -w vm.mmap_min_addr=4096 in your box (or any other number > 0) and you are safe.
sysctl -w vm.mmap_min_addr=11
Now I'm safer than everyone else.
The problem we are discussing today is CVE-2009-3547. The root cause of the vulnerability is a null pointer dereference in pipe.c. The proper fix is to patch the kernel. It just so happens that if vm.mmap_min_addr != 0 then the bug cannot be exploited to gain root access. Therefore, mmap_min_addr can be used as a stopgap measure until you are able to patch the kernel. It also happens to be a good idea to leave mmap_min_addr set to a non-zero value to guard against other null-pointer dereference bugs that may be discovered in the future.