Slashdot Mirror
Local Privilege Escalation On All Linux Kernels
QuesarVII writes "Tavis Ormandy and Julien Tinnes have discovered a severe security flaw in all 2.4 and 2.6 kernels since 2001 on all architectures. 'Since it leads to the kernel executing code at NULL, the vulnerability is as trivial as it can get to exploit: an attacker can just put code in the first page that will get executed with kernel privileges.'"
If this was Windows we'd never hear the end of it.
Now STFU.
Does this mean that Linux was never more secure than Windows--only more obscure?
sudo
Please, this is a _local_ privilege escalation. It's not like code red infecting your box remotely. A sledgehammer is also a local privilege escalation.
The biased /.er. It doesn't matter that it was a 8 year old really bad exploit. If it was MS this post would have been on the same day as it was found and everyone laughing at how lame Win is. Not for the /.ers. Nope focus on the fact the article didn't get posted here till today and that "hey, look its already been patched way back in april of this year no worries WE WIN!!
How can you trust that a user hasn't used a privilege escalation to install a rootkit already? You can't trust apt-get, or yum, or anything.
Fresh install time, surely? Back to the bare metal.
As was stated before: if someone has a local account on your Windows machine, they already own you. You DO know the difference between local and remote exploits, right? I mean, NOBODY on Slashdot would go spouting off on topics they know nothing about just to score some points for their favorite OS.
Yeah, this is a serious bug. But honestly, how many people are running real multi-user systems with multiple honest to God local users? Okay, I am, but I figure I'm probably in the minority nowadays.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
April or not, I want to know why it's taken eight years to find this flaw.
You are welcome on my lawn.
There's a theme of comments that occur every time another Windows vulnerability happens. It goes something like this:
Windows FanboiIt doesn't matter. Marketshare marketshare marketshare blah blah business drivel Linux has no marketshare!
It's ironic to now see the Linux 31337 in this meme; trying to redirect from security vulnerability to lack of marketshare by a competing OS.
But I guess maybe it goes along with the whole tired 'BSD is dying' theme.
Notes From Under *nix: blas.phemo.us
How can you trust that a user hasn't used a privilege escalation to install a rootkit already? You can't trust apt-get, or yum, or anything.
How do you know that the CD image doesn't contain hacked software?
How do you know that the compiler hasn't been hacked in with a hidden precompiled message?
How do you know that the website with the MD5 summaries isn't a Man-In-The-Middle?
At some point, you have to take a good look and decide that it's good enough. And the "compromise" position that you have to take with Linux is sooo much more secure than the Windows alternative. True, I don't know for *sure* that no local users have compromised the systems. But then, I never do, truthfully, anyway. But I do have some pretty strong assurances, and that's good enough for almost anyone.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Because we fix it instead of hushing it up until it becomes fairly well known and then waiting a month to fix it.
That said, it's nice to see the occasional vuln in Linux. Helps shut up the fanbois and keep everybody sharp. Because while under many eyes, all bugs are shallow, that only works if the eyes are actually looking.
93rd rule of Slashdot: No matter how obvious my sarcasm is, my comment will be taken seriously by someone.
Which part of "local" are you not understanding?
"Local" doesn't necessarily imply physical access. It simply means that you have gained permission to run arbitrary code as a user on the given system. For example, if you have logged into an SSH account that is local to a given machine, you are local. So first you use a remote exploit to gain local privilege, then you use a local exploit to elevate from there.
I think that's his point. You have, in fact, been able to escalate without privilege for a long time. It wasn't known you could, but that doesn't mean the bug wasn't there. It was "obscure". The reason Linux was secure from this kind of arbitrary escalation was because people didn't know the trick to doing it, not because the security was such it couldn't be done.
I'm not saying I agree with the GP 100% or anything, but he raises an interesting point. One of the oft lauded advantages of open source is the "many eyes" thing. It is claimed that there aren't major holes since so many people can look at the code. Well, this demonstrates that isn't always the case. This is a LONG standing bug. However, despite the people looking at the code, it wasn't noticed. Only now has someone discovered it.
It's somewhat ironic that this is only exploitable if you have selinux running.. (afaics)
AFAIK it's not SELinux, it's poorly-designed SELinux policies which allow any process to map pages at address zero even if they're not root or not otherwise allowed to do so.
Because while under many eyes, all bugs are shallow, that only works if the eyes are actually looking.
For eight long years no one was looking. Tell me again how the geek spins this story in a way that inspires confidence in Linux and FOSS?
This actually is a flaw in x86. Under the x86 segmentation model, it is impossible to transfer control from ring0 code to lower-privileged code. This is precisely to prevent this type of attack, where you can trick the kernel into calling a function inside user-controlled memory. (You can, of course, transfer control from ring0 to a less privileged ring, but it's far more deliberate process).
However, Linux doesn't really use the segmentation system all that much. Instead it relies on the paging model to enforce the user/supervisor distinction. Problem is, the x86 does NOT prevent code running from a supervisor page from transferring control to a user page. Intel's excuse for this is that "you can use segmentation to achieve that protection" but as we all know, nobody uses segmentation for shit.
Let me say this all over again. The bug is not in the kernel -- it was performing a NULL check which gcc was optimizing away. It is not a bug in gcc, because according to the ANSI C standard, NULL cannot be dereferenced, and therefore a dereference followed by a NULL-check is redundant and can be optimized. It is a bug in the kernel build system (for not setting the proper flags to tell gcc that's it's not compiling ANSI C code, it's compiling kernel code) and it is also a bug in the CPU itself (for allowing direct transfer of control from supervisor pages to user pages)
In normal configs, Linux is vulnerable
The problem you're describing is not an issue just for Linux but most current 'conventional' OSes. On any OS with a shared memory space as you described, if you can a) 'hack' a pointer, and b) move or map your own code to where that 'hacked' pointer is now pointing to, and c) combine this with some other exploit/bug to get elevated privileges in the code you inserted earlier and take immediate advantage of this, then you can theoretically pwn the system whatever its OS (as always, it depends on the specific circumstances).
As you say, this is fundamentally a weakness of the hardware-assisted approach to process isolation, because in a paradigm that allows modifiable pointers in userland code, neither the hardware nor the OS can ever *really* know what the pointers are actually pointing to.
It either has a ~10%-20% overhead and is insecure by design (kernel map includes calling process memory space)
Not sure I'd go as far as 'by design', at the very least its not an easy exploit to accomplish (not withstanding this latest problem), since it depends on finding at least one bug/flaw in the OS to let you do the first step of 'hacking' a pointer (and usually at least one more bug/flaw to be able to do something really dastardly), but yes, there is an overhead, and its certainly not a perfect model (what is?).
maybe it's finally time for an OS with a single memory space, like JavaOS or jxos, or even Singularity.
If they can get it right, absolutely.
In fairness however, these OSes accomplish their goal by restricting you to a type-safe language(s), in effect, they (try to) avoid the problem of pointers being 'hacked' by eliminating the presence of writable/modifiable pointers that *can* be 'hacked' within running code. They use the strictness of the language as the protection mechanism, rather than hardware assistance. This however is not trivially easy to accomplish either (see jxos and their 'Isolates' mechanism they're having to shim into their system), which is why these OSes remain work-in-progress research projects. Then, once they do get it right, we won't be able to just 'port' all our current software over and take off, nope, all the software we use now will have to be rewritten in a type-safe language that that OS supports (or thrown out!), so the switching over process won't happen anytime soon. :(
It is a 'cool' idea though, if for no other reason than it avoids the overhead of the hardware assisted model, and eliminating modifiable pointers (at the source code level) in code will allow smarter static/jit compilers to safely do *far* more aggressive optimizations than they can do now, as modifiable pointers (especially if they can also be aliased) are the single biggest headache for any optimizing compiler.