Local Root Exploit for Linux 2.6 Discovered
A new vulnerability has been discovered in the 2.6 Linux kernel that allows a local user to obtain a root shell. The bug description was posted within the last 24 hours, and includes exploit code that works on a large number of Linux installations, running kernels version 2.6.17 to 2.6.24.1.
Comment by Trip Volpe
February 10, 2008 @ 11:53 pm
It looks like this works by exploiting a vulnerability in the vmsplice system call. I’m also in CSE 451 (operating systems) this quarter, and our first real project involved writing a new system call. Whenever putting anything like that into the kernel, one of the most important considerations is ensuring that your code is completely airtight (even a crash is unacceptable), but as we see fairly often, it’s not really possible to write perfect code all the time.
If anybody’s interested, the Linux kernel code for a vulnerable version of the vmsplice syscall can be found here: http://lxr.linux.no/linux+v2.6.17/fs/splice.c#L1200
I’m not familiar with it enough myself to identify exactly where the vulnerability is, but it’s interesting that such a serious vulnerability would exist in a system call that seems to implement such a simple and important functionality. The comments sure make it sound simple, anyway. 😉
This also showcases some of the strengths and weaknesses of an open-source operating system. On the one hand, the code is available to all to view, allowing anybody to identify and report (or fix) vulnerabilities. On the other, that also means that anybody can find and exploit a vulnerability, and the lack of a single centralized “patch authority” means that some users are on their own as far as fixing their system goes.
Comment by Trip Volpe
February 10, 2008 @ 11:59 pm
Hmmm.
I just tried the exploit code on the lab Linux machines, and it works! Might be a good idea to get that fixed sometime…
Comment by cbhacking
February 11, 2008 @ 2:09 am
<tongue-in-cheek>Wow… this would have made Project 1 SO much easier!</tongue-in-cheek>
In all seriousness (and without checking the code myself), this sounds fairly close to the type of thing we doing with project 1. The primary difference is that rather than exploiting a vulnerable program with SetUID root, it’s an actual kernel code vulnerability. This is more dangerous for a few reasons: it will work even if no vulnerable program (aside from the kernel) is installed, and it may make it possible to exploit the system even through an otherwise secure program (such as an Internet-connected server) that happens to use this system call.
The proof-of-concept may not be exploitable remotely, but it’s still a major hole – all you need to do is either find a program that uses this syscall and allows the attacker enough control to pass in the exploit code, or find an exploit that allows user-level code execution (there have been a number of these; it can be ANY vulnerable program even if not SetUID root) and inject this privilege escalation exploit.
Comment by Nick Erkert
February 11, 2008 @ 6:24 am
It also seems to work on attu… It’s days like this when sysadmins take up smoking.
Comment by Nick Erkert
February 11, 2008 @ 9:23 am
For those who are still waiting for vendor patches I found a cool little kernel module that seems to foil the exploit and log the attempt.