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.'"
So that's what the NULL pointers were for.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
I use Windows!
Why the bloody hell isn't page 0 hard-wired to panic the kernel / SIGSEGV the userland when accessed?
Or I would be able to, if there were any
Long live the BSD license
In the Linux kernel, each socket has an associated struct of operations
called proto_ops which contain pointers to functions implementing various
features, such as accept, bind, shutdown, and so on.
If an operation on a particular socket is unimplemented, they are expected
to point the associated function pointer to predefined stubs, for example if
the "accept" operation is undefined it would point to sock_no_accept(). However,
we have found that this is not always the case and some of these pointers are
left uninitialized.
This is not always a security issue, as the kernel validates the pointers at
the call site, such as this example from sock_splice_read:
[snip]
But we have found an example where this is not the case; the sock_sendpage()
routine does not validate the function pointer is valid before dereferencing
it, and therefore relies on the correct initialization of the proto_ops
structure.
We have identified several examples where the initialization is incomplete:
[snip]
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.
uh huh..and the 8 years it took to discover don't matter, eh?
If this were Windows, we'd first hear about it when our machines get owned by some malware, and then it would take months for a patch to be released. Since this is Linux, expect a fix in a week or less.
Generally people don't care about local privilege escalation on Windows. Like this vulnerability.
Finally! A year of moderation! Ready for 2019?
Then why did Linus check in a patch today to fix it?
http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
Sure there are. And they are both laughing.
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.
This space for rent.
From http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html:
-------------------
Mitigation
-----------------------
Recent kernels with mmap_min_addr support may prevent exploitation if
the sysctl vm.mmap_min_addr is set above zero. However, administrators
should be aware that LSM based mandatory access control systems, such
as SELinux, may alter this functionality.
It should also be noted that all kernels up to 2.6.30.2 are vulnerable to
published attacks against mmap_min_addr.
I have checked my default Ubuntu and CentOS/RHEL boxes, and both of them are set well above 0:
root@Ubuntu:/proc/sys/vm# cat mmap_min_addr
65536
[root@CentOS /proc/sys/vm] cat mmap_min_addr
65536
[root@RHEL /proc/sys/vm] cat mmap_min_addr
65536
Check out my sysadmin blog!
No. If nobody knew it wasn't a security issue. I'm sure there are bugs on every OS with more than 8 years old yet to discover.
You veered completely off track right about here: "If nobody knew"
Seriously? Really, that's the best you could come up with? That's your apologia? How do you know nobody knew? You think the real blackhats are going publicizing their 'sploits? Blackhats these days aren't script kiddies and honest hackers, they are hard core Russian mafia doing it for cash. Your Linux systems could have been owned twelve ways from Sunday for EIGHT YEARS without you ever knowing it, and you are claiming 'it wasn't a security issue?' WTF? When did Linux get infested with idiot fanboys? Shouldn't you be slobbing all over an Apple or something? I was using Linux before you even knew what Unix was, I despise Microsoft and love open source, but a bug is a bug.
Try this one: 'No. Because it's a freaking LOCAL EXPLOIT and nearly no-one uses Linux for multi-user systems now that everyone can afford their OWN FREAKING COMPUTER.' Good lord, kids these days, gotta teach them everything.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Aw, cheer up little guy. I thought it was a very nice comment.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
And from all across the globe came the sound of geeks crying, for they would soon see their beloved "uptime" reset to zero.
Yeah, that was my fault. Sorry about that. I knew it was there, I just kept putting off fixing it or telling anyone.
In normal configs, Linux is vulnerable to this kind of problem by design because it runs unsafe programs and then for efficiency the kernel also has direct access to it's memory plus the memory for a process doing a syscall. And it's not just a NULL pointer, and preventing maps for page zero doesn't solve the problem... it just means you need to find a bug where you can corrupt a function pointer to point to mappable space.
What this demonstrates is that the cost of isolating programs from each other by using separate memory spaces has a much higher cost than commonly understood. It either has a ~10%-20% overhead and is insecure by design (kernel map includes calling process memory space) -or- it is far slower than even that, but safe (kernel memory is completely separate from process). Computers are already faster than many users need... maybe it's finally time for an OS with a single memory space, like JavaOS or jxos, or even Singularity.
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.
Of course, as this only affects 2.4 and 2.6, users of Debian stable should have no reason to worry.
See? All that testing is worth it after all!