Linux Kernel 2.6 Local Root Exploit 586
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.
Beauty of OSS (Score:5, Insightful)
On the other hand though this is the beauty of open source. The problem is now known so I'm sure a fix is already on the way.
Re:Beauty of OSS (Score:5, Interesting)
.
Note: The above assumes that the kernel compiles, which may not always go as smoothly or be as you'd like. That doesn't change the fact that it is theoretically possible, though.
Re: (Score:2, Funny)
Re:Beauty of OSS (Score:4, Informative)
Re: (Score:3, Insightful)
See, we don't download binaries from websites and click "yes" until the installer shuts up. (Though I hate to say it but there a
Re:Beauty of OSS (Score:4, Interesting)
Which it can use to modify your menus so that next time you click that "root terminal" entry the parameters to gksu are a bit different.
The patch. Everybody needs this. (Score:5, Informative)
Re: (Score:3, Funny)
Allow me to past in the first couple of lines:
Apparently, milw0rm does have a patch for that.
Re:Beauty of OSS (Score:4, Funny)
Re:Beauty of OSS (Score:5, Insightful)
Re:Beauty of OSS (Score:5, Interesting)
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
Re: (Score:2)
Re:Beauty of OSS (Score:5, Informative)
Or already here...
This appeared to work... [gmane.org]
Re: (Score:3, Interesting)
Re:Beauty of OSS (Score:5, Informative)
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 [debian.org]
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
I couldn't get the bare exploit code to compile.
The 'workaround' compiled and resulted in the oops. It did not get as far as showing whether the kernel was exploitable or not.
Re:Beauty of OSS (Score:5, Funny)
Re:Beauty of OSS (Score:5, Funny)
However, bricks = shat.
Come on now, that simply assigns shat to bricks (and that's some nasty use of the comma operator to separate statements). I think you meant:
Note that we don't have to dispose of the bricks we shit, as that's taken care of elsewhere. And of course, if we all still wrote VAX assembler we would be able to optimise this by using the SHTBRCKS instruction.
Re: (Score:3, Funny)
Re: (Score:3, Funny)
Re:Beauty of OSS (Score:5, Informative)
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.
The sound you hear... (Score:5, Funny)
Re:ssh (Score:4, Insightful)
Re:ssh (Score:4, Funny)
jessica_biel_naked_in_my_bed.c ? (Score:5, Funny)
Re:jessica_biel_naked_in_my_bed.c ? (Score:5, Funny)
You need to include justin_timberlake.h and link it with the millionaires library.
Re:jessica_biel_naked_in_my_bed.c ? (Score:5, Funny)
Thank God (Score:5, Funny)
Re: (Score:2)
Re:Thank God (Score:5, Funny)
Re:Thank God (Score:5, Funny)
I know what you mean. It's nice not having to freak out periodically like this since you live in a constant state of panic anyway.
Misleading (Score:3, Interesting)
Yet another good example of why you shouldn't hire the sysadmins who blindly use what the vendors ship, but security and performance minded sysadmins who reduce installations to what's actually needed.
Re:Misleading (Score:5, Informative)
Re:Misleading (Score:5, Insightful)
If the only people that have accounts on the machine have physical access to it, this exploit is a lot more work than just opening the box...
Re:Misleading (Score:5, Insightful)
You know, I haven't built my own kernel since 'make menuconfig' was the most advanced method around.
I got rather tired of picking and choosing what I need, just to get faster boot times.
That, and any time you need (professional) support for a third-party application, the first thing they ask you is wether you are running a stock kernel.
I -want- to be able to tell MySQL and RedHat to fight it out amongst themselves if my database does not live up to expectations.
I have better things to do with my time than to set-up and analyse endless system profiles, straces and stack dumps.
Grow up, get a real job and see what the real world is like.
You'll find that you no longer have the time to check SANS and packetstorm every day, just to see if your system is secure, spend days just to get that library to compile and then see the entire system go out the window, because it cannot be maintained (because you have be re-assigned to another project).
Re:Misleading (Score:5, Insightful)
Dunno about you, but it's my job to (among other things) keep abreast of emerging security issues, then decide on their severity and priority. A quickie scan of SANS ISC is just as much a morning habit to me as log reviews and sucking down the morning caffeinated liquid.
Shit, man... a sysadmin who doesn't check at least some source of leading-edge security news daily is IMHO either incompetent or lazy, and tend to be the ones who look really stupid once they get blindsided by a compromise.
I'd much rather be chided for pushing something off by a few minutes, than to have to explain to my boss and his peers why I didn't know about XYZ exploit, and more importantly, why I didn't do anything to prevent it from chowing down on the production servers...
(and no, I don't run Gentoo, and I avoid recompiling any kernel unless absolutely necessary).
Re: (Score:3, Informative)
Re:Misleading (Score:5, Insightful)
Re: (Score:2)
Saying 'it is the user's problem' just isn't good enough. It is everyone's problem, and if everybody tries to fix it then maybe it will go away.
Re: (Score:3, Insightful)
I notice that there are people who think otherwise, and I also notice (with some glee, I may add) that it's usually them who gets called at 5 AM on a Sunday morning because their server has been hacked or is at high risk from a zero day exploit.
Re:Misleading (Score:5, Funny)
Which reminds me, have you done your emerge -abuop6QvvvvVVvVVxz world yet today?
Re:Misleading (Score:5, Insightful)
Re:Misleading (Score:5, Funny)
Re:Misleading (Score:4, Insightful)
Suppose there is a bug in Windows (stretch your imagination to include that possibility) that is part of one of the unpopular services on by default. No one on /. would excuse it because the user (or their sysadmin) should have disabled that service.
Also, options should never, as a principle, cause security holes.
This is incorrect (Score:5, Informative)
Re: (Score:3, Informative)
2.6.14.7 does not fall within the affected range of 2.6.17 to 2.6.24.1
Re: (Score:3, Interesting)
Re:Misleading (Score:5, Insightful)
So the right answer is not 'It's not really a problem, honest!' The right answer is 'Yes, I fixed the problem on all our servers first thing this morning, with no downtime.'
Re: (Score:3, Insightful)
Re:Whatever... (Score:5, Insightful)
Out there in the real world you use RHEL because it has paid support. You then use hardware certified by Redhat and use their packages (btw. RHEL doesn't appear to be vulnerable - you get an mmap failure trying to run the exploit).
If your oracle server goes titsup and oracle refuse to support you because although you're running on the supported RHEL your cowboy IT guy recompiled the kernel and broke it.. that costs money (potentially millions if the downtime is extended). And time. And stress. And the IT guy's job, and his job reference, and, we would hope, his career.
Re: (Score:3, Informative)
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.
Re: (Score:3, Insightful)
Re:Misleading (Score:5, Informative)
to
as mentioned in http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=712a30e63c8066ed84385b12edbfb804f49cbc44 [kernel.org]
Then make and install the new kernel, reboot, and try the exploit. It should fail.
Before the inevitable occurs: (Score:5, Insightful)
The difference is that we know about this hole, and can now fix it - I'm just going to bed, and it will no doubt be fixed by the time I wake up. How many Windows security issues are known that haven't been fixed?
"Oh man, this is why Linux is great! We can find holes, and fix them, like, immediately!"
Yes, that's a strength of Linux. What I want to know is, what steps will be taken to ensure that bugs of this type - whatever they might be - don't crop up again? One advantage that a large paid organization can have is strict testing requirements - I'm honestly not sure if I believe the Linux kernel is held to the strong standards that a commercial kernel theoretically could be.
The existence of this bug is a failure on Linux's part. There's no way to get around that. Many mistakes were made, from the original code or design decision that caused this bug all the way up to it not being found until now. The bug will be fixed rapidly - but the process that let this bug be released needs to be looked at, casually at the very least, to figure out if there's a way to stop this class of error from ever happening again. (Whatever class of error it ends up being - I don't pretend to know.)
Re:Before the inevitable occurs: (Score:5, Insightful)
This is quite old code and I had to rewrite it to even compile.
Re:Before the inevitable occurs: (Score:4, Funny)
Re: (Score:3, Insightful)
what steps will be taken to ensure that bugs of this type - whatever they might be - don't crop up again?
All code in the kernel goes through a fairly exhaustive review process to the point where the major developers, like Linus, don't write code much, just review what's already been put in. If you look at the number of linux kernel exploits over the past year, you'll see that there's not a whole bunch (this is the only one I've heard of). Whether it's as good as a commercial, proprietary product, I don't know. But I do know that it's good enough to get the job done well.
Works for me too (Score:3, Insightful)
Linux opteron 2.6.22.16-0.2-default #1 SMP 2008/02/01 19:36:55 UTC x86_64 x86_64 x86_64 GNU/Linux
Is this x86/x86_64 only? (Score:5, Interesting)
Re: (Score:3, Informative)
Re: (Score:3, Funny)
I heard that the Debian Architecture group are working through the night to ensure it will work on *all* of their supported platforms. Should be on your favourite mirror by Monday lunchtime !!
Re: (Score:3, Informative)
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.
Funny comments :) (Score:5, Informative)
"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
This workaround works (Score:5, Informative)
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.
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
This also has a patch to the debian kernel tree to fix it: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=54;filename=patch;att=1;bug=464945 [debian.org]
Hopefully will hit the apt mirrors shortly, as I don't fancy trying to get my head around make-kpkg (which never worked for me) at 10pm on a Sunday.
Re: (Score:3, Informative)
Linux kenshu 2.6.22-14-generic #1 SMP Fri Feb 1 04:59:50 UTC 2008 i686 GNU/Linux
Re: (Score:3, Informative)
This flaw is CVE-2008-0600 (Score:5, Informative)
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=712a30e63c8066ed84385b12edbfb804f49cbc44 [kernel.org]
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 [redhat.com]
Fedora tracking bug
https://bugzilla.redhat.com/show_bug.cgi?id=432229 [redhat.com]
where to find in menuconfig (Score:3, Interesting)
if so then mine is ok as i dont build that in my kernel, if this is something else where can it be found in menuconfig?
SELinux? (Score:4, Informative)
yea but how do we disable it till its fixed? (Score:3, Insightful)
'Sploit needs fixing on x86-64 (Score:3, Insightful)
Every instance of "0x%lx" needs to be replaced by "%p".
The moral of this story is: Always use gcc -Wall and fraggin' pay attention to the warnings.
Re: (Score:3, Funny)
$ gcc -o jessica_biel_naked_in_my_bed jessica_biel_naked_in_my_bed.c
jessica_biel_naked_in_my_bed.c:138:2: error: #error "unsupported arch"
jessica_biel_naked_in_my_bed.c: In function 'kernel_code':
jessica_biel_naked_in_my_bed.c:159: warning: initialization makes pointer from integer without a cast
jessica_biel_naked_in_my_bed.c: In function 'main':
jessica_biel_naked_in_my_bed.c:211: error: 'PAGE_SIZE' undeclared (first use in this function)
jessica_biel_naked_in_my_bed.c:211: error: (Each undecl
Re: (Score:3, Informative)
#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.
slashdot not filtering well enough (Score:4, Insightful)
It seems to me that slashdot's system for filtering submissions is doing a very poor job these days with stories about security bugs.
Within the last day or two, we've had the following:
This is really getting to be a Boy Who Cried Wolf thing.
Ubuntu 7.10 generic kernel is affected. (Score:5, Informative)
Just fixed it. (Score:3, Interesting)
That's why I use an open-source OS. I can fix it when it breaks.
TWW
Re: (Score:3, Funny)
Ran the fix, couple of notes... (Score:3, Informative)
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.
Last resort from a cracker? (Score:3, Interesting)
Poor form, but I guess it has at least made a few more people aware of the severity of the issue.
To everyone saying "I ca fix it myself"... (Score:5, Interesting)
I mean, hacking stuff in and out of a production system kernel; surely that's a process that would require months of intensive regression testing, etc, etc? I mean, I doubt there are people that know the kernel well enough to do such changes for their own systems, but really, what percentage of you guys honestly and confidently can say "Yeah, let me just fix that for us" knowing your job is on the line if your systems crash around you.
This isn't a troll, this is an honest question.
Source of Mystery Malware Affecting Linux/Apache? (Score:4, Interesting)
It seems pretty clear that people are using other remote vulnerabilities to gain local user access and then using this local root exploit to install their "malware".
Get those boxes updated as quickly as possible, folks!
Re:For those that would rather write than read. (Score:5, Informative)
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.
Re: (Score:2, Insightful)
Re: (Score:3, Interesting)
That's still pretty dangerous (Score:2)
Re:For those that would rather write than read. (Score:4, Insightful)
A 'local root exploit' only means that you have to have a shell of some kind first. This can include an SSH shell account. This can also include any kind of non-root shell exploit.
Say that you can exploit some webapp to get a shell as wwwrun/apache/www. That combined with a local root exploit to get root. It doesn't even need to be a DIRECT shell exploit. Perhaps your hack/program opens up a port with telnet listening.
Thus all 'local root exploits' are potential remote exploits, if we allow for chaining. Chaining can be used by anyone who isn't just a script kiddie. Hell, you could probably make an auto-rooter that will chain the exploits.
Re: (Score:2)
Re:I am so depressed ... (Score:5, Informative)
http://www.milw0rm.com/exploits/5093 [milw0rm.com]
Notice the original article links to 5092.
Re:I am so depressed ... (Score:4, Informative)
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 [debian.org] 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
Re: (Score:3, Informative)
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?
Re:But this can't be real! (Score:4, Insightful)
NTFS has had that for a while now.
Suggest you check out Windows System Resource Manager
The real problem here seems to be not Windows, but your ignorance about Windows.
Re: (Score:3, Informative)
Re: (Score:3, Informative)
Re:But... (Score:4, Interesting)
The problem is, even though you're the sole user, that if other exploits appear they could piggyback this to escalate from, say, access as www-user to access as root. Got any http services on that box for your own convenience, and any of those use PHP? Based on past experiences, this might hose you. Got SSH on there? Again, based on past experiences, this might hose you. Sendmail and some kind of mailscanning? Again, this might hose you.
It's not just a matter of whether or not you trust your users - it's also a matter of whether or not you trust anyone who attempts to exploit some other service your box offers to not try for root access once they get in. "Please, Mr Blackhat, you've gained access to my box, but please don't elevate that to root!" sounds more than a little naieve, and even a little stupid, but that's exactly what people who leave a whole lot of locally exploitable vulnerabilities on their boxes are saying. By not leaving this kind of thing laying around, you are making it a little bit more difficult for anyone who does manage to gain access to your box to gain full access to it.
Security is all about healthy paranoia, and a belt AND braces AND duct tape approach can pay dividends.
Am I personally worried about this? On my work machine and servers I administer, hell yeah - always on, always connected, running various things that in the past have had vulnerabilities - of course I am, I'd be stupid not to be. At home (dial-up, behind a firewall with NAT, nothing much in the way of services, turned off most of the time even though I don't usually bother turning off my WEP-protected wireless access point), not so much - and not just because the only accounts are held by me. I don't broadcast the SSID, I have a couple of neighbors with no security on their broadband-connected wireless access points, and I don't run an awful lot in the way of remote services when I do have my home machines running. If I had broadband at home and a machine that was running anything that was remotely accessible, or if I didn't have a vertiable smorgasbord of less security-conscious neighbours - I'd fix this at home in a heartbeat.
Re: (Score:3, Insightful)
unfortunate that the exploit existed for so long, but a patch was available for my gentoo distro within four hours of the article being posted on slashdot.
It sucks, actually. The bug was clearly simple enough to patch within hours, but that didn't stop hundreds if not thousands of programmers from failing to see it for a long, long period of time. "Many eyes make bugs shallow" my ass. One brilliant eye makes a bug shallow (in this case, the exploit author).
Clearly there are not enough brilliant eyes l