Local Privilege Escalation On All Linux Kernels 595
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.'"
pwned (Score:1, Insightful)
If this was Windows we'd never hear the end of it.
Now STFU.
Security through Obscurity? (Score:3, Insightful)
Does this mean that Linux was never more secure than Windows--only more obscure?
Local Privilege Escalation On All Linux Kernels (Score:5, Insightful)
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.
Re:Security through Obscurity? (Score:5, Insightful)
uh huh..and the 8 years it took to discover don't matter, eh?
Re:pwned (Score:5, Insightful)
Re:Security through Obscurity? (Score:3, Insightful)
Does this mean that Linux was never more secure than Windows--only more obscure?
It's hardly obscure since they could look and find it, evidenced by the fact they found it.
Go try that with the Windows kernels!
In addition, there is already a patch out for this, which by end of the week will be pushed down from the distro managers. We don't have to wait years after finding it for the fix to be released, as Microsoft historically does.
In fact, why just assume this similar bug is NOT in the windows kernel? Did you check? Did any reputable security company check?
I'm not saying it is there, only that you can't easily prove otherwise.
*that* is the security being spoken of.
As far as I know, only one OS claims no exploits, and that is OpenBSD.
Re:Ahh... (Score:2, Insightful)
Re:Local Privilege Escalation On All Linux Kernels (Score:5, Insightful)
My guess is that rootkits are being updated as we speak, so get your kernels patched people.
Re:The REAL impact here (Score:5, Insightful)
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.
Re:Security through Obscurity? (Score:2, Insightful)
How do you know that nobody knew about it. It could have been a nice little tool for somebody for years.
Re:pwned (Score:4, Insightful)
Expect a source fix with no regression testing in a week or less. Wait months for the big distribution makers (RedHat, Novell) to release it to the masses.
Expect people manually rebuilding their kernel in panic, having machines rendered unbootable because they decided the 250$ bucks for the iLO Advanced license wasn't worth it since Linux never crashes, etc. pp.
Face it: IT sucks. The OS matters little.
Re:pwned (Score:2, Insightful)
Ah, I miss 1999, too.
Seriously, have you used a Windows machine at all in the past, say, decade?
A _real_ Windows machine, not the crap they sell you at Best Buy. No? OK then.
Re:Security through Obscurity? (Score:2, Insightful)
Does this mean that Linux was never more secure than Windows--only more obscure?
No. If nobody knew it wasn't a security issue.
Isn't that exactly what security through obscurity means?!
local... remote... (Score:3, Insightful)
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.
Re:Local Privilege Escalation On All Linux Kernels (Score:4, Insightful)
But if you have any programs that access the Internet that have a bug that allow running arbitrary code, couldn't a remote cracker could exploit the vulnerability in that program to invoke this bug, and through that gain root access to the machine? It sounds like the program being exploited could even be running as a regular user.
Re:Security through Obscurity? (Score:3, Insightful)
Yeah, I can't buy this, and neither should you.
Really, just because they're not common knowledge doesn't mean that no one has found them.
Re:Security through Obscurity? (Score:5, Insightful)
Does this mean that Linux was never more secure than Windows--only more obscure?
It's hardly obscure since they could look and find it, evidenced by the fact they found it.
Go try that with the Windows kernels!
In addition, there is already a patch out for this, which by end of the week will be pushed down from the distro managers. We don't have to wait years after finding it for the fix to be released, as Microsoft historically does.
In fact, why just assume this similar bug is NOT in the windows kernel? Did you check? Did any reputable security company check?
I'm not saying it is there, only that you can't easily prove otherwise.
*that* is the security being spoken of.
As far as I know, only one OS claims no exploits, and that is OpenBSD.
The transparent thing works both ways... it's easier for black hats to find holes too, by your own logic. And they can keep it secret and exploit it as long as they can. A similar bug existing in Windows doesn't prove anything and is irrelevant here. After all 'M$ can't code shit'. Linux and FOSS is commonly claimed to be more secure because of it's development model and bug free here in these parts. Any data that runs counter to this is routinely downplayed by commenters and moderators... just like your post got modded up.
Re:Security through Obscurity? (Score:3, Insightful)
Linux runs on a lot of shell servers, gameservers, webhosts etc. where normal user accounts are sold to customers. This happens much less with Windows servers which tend to be more owned and used by a single entity with full admin rights.
Re:It's from April? Really? (Score:3, Insightful)
April or not, I want to know why it's taken eight years to find this flaw.
Re:Security through Obscurity? (Score:4, Insightful)
Sure, it was patched, but it wasn't exactly all over the news. Neither is this one for Linux, but it managed to get mentioned on Slashdot.
Local privilege escalation is hard to guard against with current mainstream operating systems. The attack surface is very large and it is hard to completely verify interfaces. That said, Linux team seems to be doing fairly well overall. We're certainly a long way from the "good" old days when crashme would crash pretty much any Unix system. OpenBSD is doing even better, masturbating monkeys or not.
Re:pwned (Score:2, Insightful)
Mmmm, yeah, I'm gonna need you to look up the meaning 'local exploit,' mkay?
Re:pwned (Score:3, Insightful)
Of course we'd never hear the end of it, because we paid a shitload of money for a system that would be vulnerable for months until MS would decide to release a patch that wouldn't conflict with the rest of the bloat. That wasn't always the case, but it's what happened most of the time when Windows (as an operating system) got pwned with an exploit like this. There are still tons of unpatched Windows computers infected with Blaster... as long as you still hear about Blaster, you'll still hear about the vulnerability. That's why you'd never hear the end of it.
Re:I can hear the OpenBSD users laughing already.. (Score:4, Insightful)
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.
Re:The REAL impact here (Score:2, Insightful)
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.
This reminds me of why I use linux... (Score:4, Insightful)
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.
Re:pwned (Score:3, Insightful)
The flaw has been around since 2001.
There goes your theory. ;)
Re:pwned (Score:4, Insightful)
Yes, hardened windows is reasonably secure. After you spend an hour or two installing all the third party software and configuration settings you need to prevent being owned in under five minutes. Or you can just install Ubuntu.
Yes, Ubuntu. Which apparently you don't need to configure at all to get owned.
Seriously, in a story about how trivial it is to get code to execute as root you post a comment about how much more secure Ubuntu is than hardened Windows?
Re:pwned (Score:3, Insightful)
Buzz off, little worker bee, its simply not the case: this happens once every, say, couple to four years in Linux. Microsoft has one of this bugs every couple of sundays.
Citation needed.
Local vs. remote (Score:3, Insightful)
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.
Re:Security through Obscurity? (Score:5, Insightful)
Also, did you bother reading what this exploit does? It is very bad because it allows user programs to gain administrator privileges. This is insecure because it puts Linux in a category that's as insecure as all pre-vista windows computers and also the UAC-enabled-because-else-it-is-useless vista and 7 computers. That's the problem here, it moves Linux to a windows state...
Finally, it is easier to find flaws in Linux, this increases the chances blackhats found bugs, but it also increases the chances someone else will find it in paralel, preventing your hypothetical situation...
Ironically, it is because of some artificial obscurity that this bug was present and took so long to find. Most vulnerabilities aren't caused by obscure optimization issues, and are findable in source code, those were a non-issue thanks to the lack of obscurity. So this actually proves obscurity != security.
Re:Security through Obscurity? (Score:3, Insightful)
The fact that Travis and Julien found it after eight years pretty much means that the flaw existed in obscurity.
Except for the fact that it was out in the open (being open source and all), which pretty much means it was not in "obscurity".
Just because something isn't known doesn't mean someone is trying to hide it.
Re:local... remote... (Score:4, Insightful)
nobody (the apache account) is a local user.
But it was there the whole time (Score:3, Insightful)
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.
Re:Security through Obscurity? (Score:5, Insightful)
Security through obscurity does mean the thought that that as long as no one knows about it, it's not an issue. Being open source doesn't make you immune to this. What would make you immune to this would be formal testing and security audits of every component, like is done on things like the space shuttle. This is generally prohibitively expensive for situations where actual life and limb danger isn't a factor, which is why no commonly used operating system implements this strict security level. Sure, having a lot of eyes looking at the Linux kernel helps (and it eventually worked in this case) but just being open source doesn't mean it's secure.
Re:local... remote... (Score:4, Insightful)
Local exploit in kernel + arbitary code execution exploit in network service = remote exploit.
You know, like running WordPress.
It would be quite an accomplishment to introduce a remote exploit directly in the kernel.
Re:pwned (Score:3, Insightful)
So wait, the "exploit" is to run untrusted code as admin? That is not a privilege escalation attack. How is this different than running any malicious code?
Re:I don't get it... (Score:4, Insightful)
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.
Re:Local Privilege Escalation On All Linux Kernels (Score:3, Insightful)
This is easily used as a remote exploit from the looks of it. Someone correct me if I am wrong here. Some of the new linux users are likly getting the impression you need to be physically sitting at the machine.
Say you have virtual server somewhere as is common to most low end VPS hosting companies with linux running on it with a reseller account. What is there a few million of these or more around the World likly?
You have given clients ssh access to use sftp. So, they have limited local user rights, if they are not properly jailed.
In theory then this is part of a remote exploit on certain systems that will give elevated privileges.
Am I right about this?
Re:pwned (Score:4, Insightful)
Re:pwned (Score:5, Insightful)
How much local privilege escalation vulnerabilities normal windows users worry about?
They probably don't worry about it at all because the vast majority of Windows users log in and run with an administrative level account in the first place.
Re:Security through Obscurity? (Score:1, Insightful)
At some point, someone curious will get hacked, and wonder how the hell that happened, and track down the exploit.
And how?
Eyes Wide Shut (Score:3, Insightful)
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?
Re:Security through Obscurity? (Score:3, Insightful)
You clearly don't understand what is meant by quick. Quick is the time it takes to patch the bug from the point it's determined that it exists.
How do you know when Microsoft plugs a bug in the Windows platform? Do you keep track of their internal repository? What matters is when the patch gets to the users of the system, not some bleeding edge repository. It's still not in the hands of Linux users. If it gets there in less of the time than Microsoft can push a patch out for their platform, then it's faster. It being in the bleeding edge repository is meaningless.
Re:pwned (Score:3, Insightful)
This is a flaw in x86 (Score:3, Insightful)
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)
Re:Vulnerable by design (Score:4, Insightful)
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.
Re:Security through Obscurity? (Score:1, Insightful)
And that Windows exploit had been around since Win2K SP4 (a very long time), old bugs aren't that uncommon in any OS, the important thing is that they get fixed rapidly once they get discovered.