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."
Patch (Score:5, Informative)
sysctl vm.mmap_min_addr (Score:4, Informative)
'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.
Re:Isn't this a dupe? (Score:5, Informative)
Just type sysctl -w vm.mmap_min_addr=4096 in your box (or any other number > 0) and you are safe.
Re:Another story that isnt a story (Score:3, Informative)
But the bug is not exploitable on ubuntu, because they set vm.mmap_min_addr > 0 by default.
Full quote from article (Score:3, Informative)
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.
Re:Patch (Score:5, Informative)
You can either do
# sysctl -w vm.mmap_min_addr = 65536
and redo that every reboot or do
# echo "vm.mmap_min_addr = 65536" >
#
and be done with it.
Bishop bashing bonobos (Score:3, Informative)
Re:Isn't this a dupe? (Score:3, Informative)
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.
Re:Isn't this a dupe? (Score:5, Informative)
$ 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 [debian.org]
https://lists.ubuntu.com/archives/ubuntu-devel/2008-July/025805.html [ubuntu.com]
http://www.securityfocus.com/bid/26831/info [securityfocus.com]
Ubuntu not necessarily safe (Score:3, Informative)
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)
Re:standard author/exploiter response? (Score:2, Informative)
That is being solved with Filesystem capabilities [lwn.net]. Fedora 11 still has ping as setuid, not sure if Fedora 12 beta already switched it
Re:Isn't this a dupe? (Score:5, Informative)
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.
Re:standard author/exploiter response? (Score:3, Informative)
Not necessarily. You can create raw sockets with some limitations without root access on OS X. There's enough control to implement ping, but not enough to forge.
Re:sysctl vm.mmap_min_addr (Score:3, Informative)
That's weird, because 9.04 gives: vm.mmap_min_addr = 65536 and so did the 9.10 desktop version a few posts up.
You probably don't have Wine installed. AFAIR Wine needs it set to zero to run some old 16-bit applications, so installing Wine installs a config file which sets it to zero.
Re:Same Exploit from July? (Score:2, Informative)
So it's really a bad design on Intel chips, that all operating system have to work around, except Windows which requires it to work like this... ...and on most Linux and BSD systems it will not work even if unpatched ... and it has already been patched ... and you need to be able to get a user on the local machine to run an app to exploit it (most users install from the Package Manager and so will never run a random downloaded app), and this does not appear to be a remote exploit?
Re:Ubuntu not necessarily safe (Score:3, Informative)
Re:Isn't this a dupe? (Score:3, Informative)
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...
Re:Isn't this a dupe? (Score:5, Informative)
Ubuntu sets this to zero if you have wine installed.
Re:Ubuntu not necessarily safe (Score:5, Informative)
Here's a fun tag line, "Windows applications can even make Linux less secure!"
Re:Somebody fill me in.. (Score:3, Informative)
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. :)
Re:What design choice? (Score:5, Informative)
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.
Re:Isn't this a dupe? (Score:3, Informative)
SUID root yields root... but, wait... (Score:3, Informative)
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.
Re:And? (Score:4, Informative)
Torvalds is absolutely correct, the whole issue is idiotic and isn't really an "exploit" because it doesn't result in ANY privilege escalation. (You must be root to run an exploit that gives you, um, root!) However, ego-starved security people get to jump up and down thumping their chests about how they h@x0r3d an extremely common Linux distribution and get their names splashed all over the press. Yeah, and instead of mmapping NULL, you can just 'insmod /my/evil.ko' and get the same effect. Sigh.
Those of us who know anything about security just ignore these "researchers". There are far more important bugs - even far more important security bugs - than a root-to-root non-issue. I'll happily patch my system with the next set of kernel updates, but I don't intend to grab it any sooner. It's more important to me that my system stay up and avoid regressions than fix a root-can-get-root non-exploit.
Re:Isn't this a dupe? (Score:4, Informative)
Re:Isn't this a dupe? (Score:3, Informative)
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.
Re:What design choice? (Score:5, Informative)
mmap(0,
char *p = NULL;
*p = 'a';
address 0 now contains the letter 'a' and the program does not fault.
The idea is that if you do the mmap in userspace, fill that area with specially crafted information, then cause the kernel to hit a bug in the software (in this case a pipe) which dereferences a NULL pointer, you can make it operate on data you control. This is due to the fact that userspace and kernel operate in the same virtual address space. Sometimes (often?) this means you can take over the box.
mmap_min_addr tries to address this problem by disallowing a program from mapping the low virtual address space. That means it ONLY affects the class of bugs that involve a NULL pointer. If it's a corrupt pointer instead a NULL pointer mmap_min_addr is totally useless. For either class of bugs hardware segmentation could help. It wouldn't be a security panacea, but it would eliminate the need for the specific hacks which both Linux and BSD use.
Re:I'd rather pay $400 for bugs likes this (Score:2, Informative)
The RHEL patch was released yesterday: https://rhn.redhat.com/errata/RHSA-2009-1548.html [redhat.com]
Re:Same Exploit from July? (Score:3, Informative)
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.
Re:Ubuntu not necessarily safe (Score:2, Informative)