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!
Does this mean that Linux was never more secure than Windows--only more obscure?
Why the bloody hell isn't page 0 hard-wired to panic the kernel / SIGSEGV the userland when accessed?
Here's the real one- linked from (mostly) useless article.
http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html
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.
Is this something that SELinux would protect against?
Oh how I wish 'ksplice' was more widely adopted in my deployed distro at work...
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.
Linus committed a patch correcting this issue on 13th August 2009. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e8945cf0f1b98
Within a few days, patches will be released to all the OSS vendors. Admins will be inconvenienced by a reboot.
Even that last bit is avoidable, if you have Ksplice installed :D
where's the source?! I want to try it. On my box.
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
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.
Sure there are. And they are both laughing.
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.
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.
Check out my sysadmin blog!
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
... I don't get it... Stallman uses Linux...
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!
Well by that logic 99% of windows users haven't used a real windows machine either.
April or not, I want to know why it's taken eight years to find this flaw.
You are welcome on my lawn.
If this was Windows we'd never hear the beginning of it. How much local privilege escalation vulnerabilities normal windows users worry about? Are the remote vulnerabilities (and the ones that don't need to escalate, as run as the current user) the ones that get lots of publicity. And you got from time to time a number big enough of remote vulnerabilities there to consider them the only ones that matters.
Of course, if you add a local privilege escalation to a some app remote vulnerability that enables to run code, even if is with low privileges, there you have a potential remote root exploit. Is something to care about, but odds are low that a lot of systems will be affected.
Yeah, I know, I nearly cancelled the post after I wrote it.
Desktop Windows /is/ Windows, but Windows Servers are far more inherently secure than Windows Desktops, simply by the way that they're operated. It was a bad comment.
Check out my sysadmin blog!
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.
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.
The flaw has been around since 2001.
There goes your theory. ;)
It looks like RHEL's mmap_min_addr (cat /proc/sys/vm/mmap_min_addr) is set to 65536 by default. According to the vulnerability posting:
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.
So, if you're running stock RHEL 5.3 without SELinux, you should be safe?
I'd rather expect a patch within 4 hours (cutting functionality) and a real fix within 24-48 hours and then I would expect most big distributions to have fixed packages out in less than 5 days (linux kernel takes a while to compile). More rapid distros might even have two fixes - a fast fix within 24 hours and a real fix in less than a week after that.
Replying to myself, with additional information for the OP: And how long have we heard about this? We're already so used to Windows exploits that we don't even care much about them...
And if any of us would have read the article before posting we would know that a typical one-line fix is right there in the article and has been commited into the kernel mainline yesterday.
Seriously, how hard is it for the OS to just blow up whatever program is running if it tries to access the memory location NULL, period?
That depends on whether you're running this OS on a PC or a C64. Programs on a C64 are expected to access memory-mapped I/O registers at $0000 and $0001.
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.
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?
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
You could measure it with a stop watch.
Indeed. Patch was committed 16 minutes after that blog post and 3 hours, 57 minutes before this story hit the front page.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e8945cf0f1b98
upon the advice of my lawyer, i have no sig at this time
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.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
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.
Um...are you referring to a physical attack? No unencrypted machine is even remotely resistant to that.
This particular vulnerability probably affects ubuntu (depending on the mmap status; certain default settings can actually prevent this), but I'm speaking generally.
93rd rule of Slashdot: No matter how obvious my sarcasm is, my comment will be taken seriously by someone.
Probably don't need to install the patch then. Or keep the machine powered on, for that matter...
You're special forces then? That's great! I just love your olympics!
Committed to the mainline kernel != Available as an update to [CentOS|RedHat|Debian]
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.
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.
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?
Well its not trivial. This is not a remote exploit, its local.
NO SIG
Well - I'm searching for Linux botnets that have been created by this exploit. Searching . . . searching . . . searching . . .
Dang, I'm not finding any.
How about Windows botnets? WOW, will you just look at all of them? http://www.secureworks.com/research/threats/topbotnets/
I sure wish Linux would get off their dead arses and patch this problem. Sure would be nice if they can get it done in less than a month or six, like Windows!! Oh - wait - what? Linus committed a patch correcting this issue on 13th August 2009.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e8945cf0f1b98
I guess I'll hold off on pushing the panic button. I see no need to "upgrade" to Windoze, LMAO
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
That's right. It's a trivial local exploit. Those aren't mutually exclusive.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
Modern windows has many levels of "admin".
But let us say that the admin accounts are are now by design almost the same as regular user accounts. By default they should not be able to harm the system. If you deliberately elevate an application to full rights (equivalent to using sudo to run the program) then it can do anything.
The problem here is that an unelevated application can just inject code directly into the memory space of certain other unelevated applications which can elevate themselves at will without user interaction.
This is a broken design. It is equivalent to having some normal applications that can just call setuid(0) and be granted full root rights without any user input, and then having a way for other normal applications to span a new thread in the other process running arbitrary code.
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
In a week or less?
Linus already patched it.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e8945cf0f1b98
He wrote it at 8:28AM and committed it at 10:57AM this morning. Expect to see it in your repositories tomorrow, if not sooner.
Running with Linux for over 20 years!
This is the windows newbs one chance to stick it to the Unix guys, don't fuck this day up for them!
You must be mistaken. rjstanford is the computer.
Exception Duck - may or may not contain chicken.
Possibly, for sufficiently loose definitions of "much more".
Linux kernel 2.0-2.6: 279 Secunia advisories, 473 vulnerabilities
Windows 2000 Server + Windows Server 2003 Standard + Windows Server 2008: 472 Secunia advisories, 580 vulnerabilities
It's also worth noting that kernel 2.6 alone contains 186 advisories for 352 vulnerabilities with 6% unpatched. Windows Server 2008 contains 40 advisories for 82 vulnerabilities with 0% unpatched.
So there's the math. Keep in mind that's comparing an entire server OS with just the Linux kernel.
We are now that picky...
This is Slashdot. We've always been that picky.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
Parent is not a troll. Local Exploit still means a bug in firefox can leave your box totally "PWND!" A local exploit is more dangerous for a desktop computer than a server. but is still a very real concern.
Thats what I get for sending you to do the math. Im still too lazy to go check it out and look at methods, years and the rest.
||sarcasm|| I take your analysis as true and hereby declare that windows has been exploited lesser than linux, has less malware against and is inherently less prone to attack than linux or turning into a braindead spamzombie than linux. ||end sarcasm||
Happy?
NO SIG
Windows Servers are far more inherently secure than Windows Desktops, simply by the way that they're operated.
Wait, what?
Linux is ready for the desktop!
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.
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!
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?
(Sigh) I miss KESU and the constrained addressibility of ring-fenced instruction sets. Oh, VMS, Oh my heart!
Do not mock my vision of impractical footwear
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)
"A common defensive technique. X isn't the REAL X, so it doesn't count!"
That's called the "no true scotsman" fallacy (http://en.wikipedia.org/wiki/No_true_Scotsman).
It's also worth noting that kernel 2.6 alone contains 186 advisories for 352 vulnerabilities with 6% unpatched. Windows Server 2008 contains 40 advisories for 82 vulnerabilities with 0% unpatched.
Your comparison is very flawed and meaningless. Linux kernel 2.6.0test was released in 2003--IT HAS BEEN AROUND 5 YEARS LONGER THAN SERVER 2008! If you want your math to actually make a real point try integrating the vulnerability rate of each OS over the same time domain. Simply put, you have to look at the combined vulnerabilities reported by Windwos Server 2003 AND 2008 when comparing against Linux 2.6.x kernel based OSes.
More proper numbers for Windows would be 242 advisories for 341 vulnerabilites. Slightly lower vulnerability count but quite a few more advisories. 6% of these vulnerabilities also remain unresolved. These numbers do not show Microsoft having any meaningful advantage in quality over the Linux kernel
And, to be more fair still, you should compare OS to OS as you said, rather than OS to kernal. For RHEL5 OS the stats are 272 advisories for 828 vulnerabilities and zero unresolved (suggests that one advisory and pne patch probably solves many separately counted vulnerabilities--perhaps because Linux-based OSes leverage shared libraries far more than Windows?) Keep in mind, however, that Comparing SLES or RHEL strictly speaking wouldn't be a complete comparison either, because in Linux OS distributions many applications are included where the equivalent in Windows would be separate (possibly extra-cost) add-ons.
Furthermore only counts are considered above, with no factor for intensity. Windows server 2008 has more than double the rate of "highly critical" vulnerabilities (35%) than does RHEL5 (16%) and it is well known that Linux exploits are far less likely to be directly remotely exploitable than is the case for Windows exploits.
Yes, MSFT has made great strides in closing the quality and security gaps in ther server OSes (quality is still sorely lacking in their desktop offerings), but even if Windows was perfect I'd still prefer a Linux OS or OpenBSD:
* can't afford Ballmer'$ ga$
* Windows is closed--I don't trust what nobody but the vendoar/author can see. Secunia et al can only report what they can observe from behaviour. As in this reported Linux exploit, third-parties can perform extremely detailed analysis with source code at hand, often releasing the patch to plug the exploit right along with the exploit itself.
* licensing and actrivation take a lot of time and resources that serve no practical purpose than to enforce an increasingly questionable business model--Activation is pure bulls**t. I've wasted FAR too much time on clients issues where the root cause of functional deficiencies was improperly activated/licensed closed software (be it Windows or others). I've HAD it with closed crippleware.
* I like to tinker. I like to build. The playing field is for more flat in Free software land than in Windows land. I can reconfigure kernel modules, choose which web server, DNS server, email server I want to use and evaluate them truly on their merits. In Windows, if you think IIS or Exchange or MS DNS Stinks, you can try the alternatives but they always seem hobbled by comparison. MSFT never lets third parties play by the same rules, especially when server apps are considered "windows componenets" like with IIS and DNS. They get to leap MSFT's long-professed "chinese wall" to get total access to OS internals info others do not have. ANYONE who wants to write server apps on a Free platform has the same access to info.
XP Home Edition, Unpatched 12% (27 of 229 Secunia advisories), Most Critical Unpatched: Moderately critical.
Ubuntu 9.04, Unpatched 0% (0 of 50 Secunia advisories).
Keep in mind that Ubuntu is also affected by standard apps like OpenOffice.org, Firefox etc. If you're going to pick server versions to prove a point...
But it wasn't a real "no true scotsman" fallacy. After all, it didn't involve a scotsman. :-)
The Tao of math: The numbers you can count are not the real numbers.
I thought these nonsensical cherry-picking comparisons using Secunia or any other site that doesn't track Linux, were dead?
I hadn't heard that, let me see if Netcraft confirms it.
Linux 2.0 : 1 Secunia advisory, 0 vulnerability
Linux 2.5 : 2 Secunia advisory, 0 vulnerability
I can be kind too :
Linux 2.2 : 8 Secunia advisory, 5 vulnerability
People have been quick to point out that it wasn't a good comparison to include 2.0 or 2.2 because of how old they are. I frankly thought it would make the numbers for Linux look better if they covered 5 versions vs. 2 versions. 2.4 and 2.6 between them have 268 advisories for 468 vulnerabilities, I thought if I bumped that up a little to 279/473 and included 3 other versions it would be more kind to Linux. So that's where my agenda is.
I frankly find it funny that I asked a guy to back up his claims, quoted stats from Secunia (which he asked me to do, by the way), and now people assume I have an anti-Linux, pro-Microsoft agenda. That's not even remotely true, I haven't even stated my opinion on either OS (in this thread, before today, anyway). I've mentioned in a couple other replies today that I consider Linux to be the superior OS of the two, but people have become very defensive.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black