Slashdot Mirror
Linux Kernel 2.6 Local Root Exploit
aquatix writes "This local root exploit (Debian, Ubuntu) seems to work everywhere I try it, as long as it's a Linux kernel version 2.6.17 to 2.6.24.1. If you don't trust your users (which you shouldn't), better compile a new kernel without vmsplice." Here is millw0rm's proof-of-concept code.
Or even a few hours. The few significant holes in OSS operating systems and programs are always patched so quickly. However, Microsoft takes months, even years to patch the thousands of holes in Windows...
:) Is my kernel version effected?
*checks kernel version* 2.6.23.8-34... wow I'm out of date
I just successfully used this exploit on a Fedora 7 box running 2.6.22.4. A bit out of date, yes, but a great deal of "home users" who are running Fedora, Debian, Ubuntu (especially Ubuntu), etc., either don't know how to compile their own kernel, or don't care enough to try. Not everyone who uses Linux is going to bother compiling a custom kernel in order to fix a problem like this, especially if they don't have the skills of a sysadmin.
Nope, all you need is remote access to a local user account via ssh or something. Many users use weak passwords. Now you won't have to guess the root password.
Yes, I just verified the exploit on Linux 2.6.17.13 (Slackware 11.0) and Linux 2.6.21.5 (Slackware 12.0) and it works as advertised.
Agreed. I'm a sysadmin who "blindly uses what the vendors [RHEL and CentOS] ship", not because I don't know how to recompile a kernel, but because sitting around and compiling a customized kernel for every server we have would be a complete waste of time.
There are some pretty funny comments in the source code, regrettably, most people won't understand them. Hell, as a Czech, I *am* probably supposed to understand them, if it were not for the obscure north-eastern dialect of Czech that all the rest of our country finds hilarious (and incomprehensible at the same time).
..." [last for four words utterly incomprehensible :)]
:)) makes me think that had drunk quite a bit before he wrote these gems. Pity that I don't have a good dictionary of spicy English. I'm just rolling on the floor and seriously laughing. :) Oh, and the exploit works, which is not that *funny*.
"Dovalim z knajpy a cumim ze Wojta zas nema co robit, kura." == something like "Just returned from the pub and saw that Wojta [a machine? Or a person? Unclear...] has nothing to do." [The last word might be a Czech expletive with a typo...?]
"Gizdi, tutaj mate cosyk na hrani, kym aj totok vykeca." == something like "Here's something for you to play with, boys,
"Stejnak je to stare jak cyp a aj jakesyk rozbite." == "Anyway, it's old as hell and somehow broken anyway"
The style (no way am I able to render *this* in English
Ezekiel 23:20
Or already here...
This appeared to work...
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953
The workaround posted in a follow-up in that thread works. I had a few vulnerable (tested) machines that I cannot reboot even if a patched kernel is released in the near future. I tried that fix, then tried the exploit again. The exploit no longer worked after using the fix (workaround).
Those machines were debian x64.
Ubuntu kernels do not appear to have vmsplice enabled by default.
Managed to get it to run on my machine (Debian). Gave me root access just as promised. Funny though that I still can't run administrative functions (like ifconfig) without running them with an absolute path (little comfort though).
nobody$
[..]
[+] mmap: 0xb7f29000
[+] root
root# ^D
nobody$
[..]
Exploit gone!
nobody$
[+] mmap: 0xb7f34000
[-] vmsplice
nobody$ no root for me anymore!
By Morten Hustveit:
"a modification of the exploit that finds the address of sys_vmsplice in the
kernel (using
(using mmap of
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953#14
Uh oh. There's another link, (not the one from the /. article) that worked on my machine:
http://www.milw0rm.com/exploits/5093
Notice the original article links to 5092.
FLR
As it's all about VM handling, I'm not sure, maybe some platform might give a panic, maybe some will use a different codepath, but it seems to be high-level enough that it is common code for all architectures. However, the only parts that are specific for x86 and x64 in the actual exploit are really the exploit code that's called within the kernel. As it is inline assembler and calling-convention specific, one would need a separate set for each platform. This is just like a user-space buffer overflow needs a specific exploit per platform, although there might be a common bug.
Upstream patch for the vulnerability tickled by that specific exploit is here
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=712a30e63c8066ed84385b12edbfb804f49cbc44
Red Hat tracking bug (Enterprise Linux 5 is affected, but 4,3, and 2.1 are not)
https://bugzilla.redhat.com/show_bug.cgi?id=432251
Fedora tracking bug
https://bugzilla.redhat.com/show_bug.cgi?id=432229
Doesn't require shell access, it only requires the ability to run arbitrary code. If you're able to upload a program or CGI script that will run on the box, then you can upload this exploit code in its place.
There's nothing special about "/bin/bash" exploitation can just as easily be another program you upload that is run instead of a shell.
Well, I can tell you that SELinux (enforcing, targeted) on Fedora 8 was no help in preventing this exploit. Does "strict" make a difference?
the growth in cynicism and rebellion has not been without cause
What is important is whether the explotable code is being run. This is only relevant to VMs. Very few Linux phones etc will be using VMs and probably none are using this explotable architecture.
Engineering is the art of compromise.
No it doesn't.
You know, there is a difference between trolling and pointing out the flaws in your reasoning. Just saying.
Would it be of interest to do so here on slashdot, considering that the relevant information is only a few clicks away? The short of it is: If you use software that doesn't require 2.6.17 or newer, it won't need vmsplice (because vmsplice didn't exist before then), and if you do run software that hard requires 2.6.17 or newer, chances are it won't use vmsplice anyhow.
No, that's correct enough. It would probably be better to say "Linux Kernel 2.6 Function Local Root Exploit", but that's splitting hairs.
However, the "seems to work everywhere I try it, as long as it's a Linux kernel version 2.6.17 to 2.6.24.1." is, I believe, misleading. One need to keep in mind that his "everywhere I tried" is likely not representative for those with an urgent need to patch against this. That's what I think is slightly misleading. It's like if an error in the M$ kernel only affecting those with IIS installed would necessitate a need to immediately patch ALL M$ servers.
I did a "grep -i" on the term "splice" in my /usr/src/linux/.config and it came up empty.
I did not include KVM support in my kernel on purpose.
As this http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=9;filename=patch;att=1;bug=464953 patch points out, it's in the general fs splice.c code, so I think it is more serious than I originally had thought.
For some reason, (if someone can substantiate this I would appreciate it) I could get neither code to work on a CentOS 4.6 machine setup as a server).
I'm buying into the idea that it may be based (a little) on kernel config options, but an official patch would be bet
FLR
The poster who said that Ubuntu kernels are not affected was incorrect, at least partially. The exploit code works as advertised on my Ubuntu machines, both of which are running 7.10 with the latest generic kernel image.
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/190587
It's confirmed on some Ubuntu versions, and it works on my Ubuntu Gutsy (7.10) kernel (2.6.22-14).
I think the [MS Word] paperclip is a great idea. - Miguel de Icaza
BTW: Has anyone figured out if there is an option you can disable in make menuconfig that removes vmsplice(), or is it integral to the kernel?
Linux 2.6.24.1
commit cece280a46c9b5c0adb4d5251f42c082a578e1ad
Author: Jens Axboe
Date: Fri Feb 8 08:49:14 2008 -0800
splice: missing user pointer access verification (CVE-2008-0009/10)
patch 8811930dc74a503415b35c4a79d14fb0b408a361 in mainline.
vmsplice_to_user() must always check the user pointer and length
with access_ok() before copying. Likewise, for the slow path of
copy_from_user_mmap_sem() we need to check that we may read from
the user region.
Signed-off-by: Jens Axboe
Cc: Wojciech Purczynski
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Linus Torvalds
It looks like the fix for this exploit have been released 3 days ago.
Nothing to see here, move along.
Reply was to a post about how companies should hire decent sysadmins who compile their own kernels for efficiency and security. Read before you reply.
Vmsplice is part of the core kernel, it is not a configuration option. It is used all over the place.
Interested in open source engine management for your Subaru?
disable-vmsplice-if-exploitable causes kernel oops on Debian Etch with kernel 2.6.18-3-xen-686
In the free world the media isn't government run; the government is media run.
to
as mentioned in http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=712a30e63c8066ed84385b12edbfb804f49cbc44
Then make and install the new kernel, reboot, and try the exploit. It should fail.
Get your own free personal location tracker
So far it's come up with "function not implemented" on all my Ubuntu Dapper LTS servers, which means most of my machines, but it did come up "Exploit gone!" on my 7.10 X64 and a couple of Debian 4.0 boxes.
Note that if you compile disable-vmsplice-if-exploitable.c on an X86 box you'll need to compile it again for any X86-64 boxes you have.
"Ain't no right way to do a wrong thing."
Everyone who is recommending that people should run the 'disable-vmslice-if-exploitable' file should stop doing this!
The fix does patch the syscall, yes, BUT, in doing so it tests the exploit. From what i have gathered in testing this myself, exploiting the bug actually corrupts the kernel memory map leaving your system in an undefined state, absolutely anything could break, including the possibility of the filesystem driver writing crap to your disk. BEWARE if you use this fix, or take out the test mechanism!
http://www.inspircd.org - Modular C++ IRC Daemon
Troll?
._.
Anyway, you do realize what local root exploit is don't you? A normal user mode program could run this and gain root access. Say you had SSH running under uid for nobody, Now normally a hole in that would mean that the cracker just has access equiv to 'nobody', but with this, 'nobody', can become root.
Or a more likely scenario, say you were running a browser with a remote code exploit. Normally the browser would only have access as your user account, but with this now your browser has root access.
> The security linux enjoys is because it is 1% market share, so bad guys don't care about it.
This is probably true when it comes to malware targeting grandma, (note: you don't need a root exploit to do plenty of bad things, like install a keylogger on a user's session; IMO things like browsers should one day be relegated to another user as well) but you don't you think that people would be interested in breaking sendmail or BIND and the overwhelmingly UNIX (and increasingly GNU/Linux) systems that they run on? (They have in the past, many times in fact...)
I think this position understates the incentives to attack Linux, because, quite frankly, virtually everything actually important infrastructure-wise runs on a UNIX-alike nowadays (VMS holdouts withstanding), and now it seems clear that with the possible exception of Solaris that all UNIX-alikes except Linux are in their death throes.
> There are flaws in both open source and closed code, but I would say that closed code is better for security.
I disagree. With closed source there is substantially less research and review that goes on. Important security bugs that are thought to not be "in the wild" can be swept under the rug indefinitely because they don't jive with business goals of the owning company. In the case of open source development any agent with an axe to grind (and oftentimes clients to reassure) can make it their priority to get the damn thing fixed.
I think an axiom people have when they hold security-by-obscurity as a credible advantage is a defeatist regarding the nature of bugs: one *can* write a nearly-correct code; see qmail, TeX, dovecot, djbdns, and OpenSSL. It just takes time, effort, and sound engineering (which may include the limitation of scope, something that is hard to do in product-oriented firms). Linux 2.4 may be reaching this point; that's probably why NASA is considering deploying it on things that are actually important.
vmsplice exploit fix
Have you got your LWN subscription yet?
Funny you should mention that. This bug was fixed in a commit yesterday afternoon (http://lkml.org/lkml/2008/2/10/8).
RTFM
No, only Windows uses the retarded long/4 pointer/8 on 64-bit. Linux correctly has 8 byte longs and pointers for x86_64.
./test
#include
int
main(int argc, char *argv[])
{
printf("%lu %lu\n", sizeof(long), sizeof(void *));
return 0;
}
$ gcc -Wall test.c -o test
$
8 8
I agree that %p would be the better choice, but using '%lx' should only provoke warnings on a 32-bit distro.