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.'"
Here's the real one- linked from (mostly) useless article.
http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html
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]
Little faster than that:
-
Solution
-
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
-
Credit
-
This bug was discovered by Tavis Ormandy and Julien Tinnes of the Google
Security Team.
) Human Kind Vs Human Creation
) It'd be interesting to see how many humans would survive to serve us.
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
SELinux makes the problem worse. Without SELinux, there's a variable that specifies the lowest page in memory that a process can map. If you can't put anything at address 0, jumping through a NULL function pointer isn't as big a deal.
With SELinux on, that variable is ignored, and you can map at address 0 to your heart's content.
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!
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.
Yes, it's called hardware level paging ... The problem is from how the exceptional condition (null pointer access) is handled by the kernel, and not the fact that NULL was called.
No, it's not. The problem is that the kernel also has access to the process's memory, so if the process mapped page 0 as r-x then the kernel also has that page. So when the kernel jumps to NULL through a function pointer, it runs whatever code the process put there.
This mapping is done for efficiency because otherwise any system call would flush TLB at least *twice* and it would be slow as hell.
Hardware memory protection is as old as dirt, but it's also a brutish fossil, symbolic of a decayed era, gratefully forgotten.
SELinux is currently weaker in this area for local users. It is stronger in this area for remote network facing daemons. See http://eparis.livejournal.com/ for all the details. Blanket statements in either direction on SELinux and NULL ptr exploits are wrong.
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
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!
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
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.