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.
I don't think I'm the first of us to say "Ah shit".
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.
I never get used to these constant resurrections
And the next sound you shall hear are millions of nerds rushing into their offices to compile a new kernel on a sunday afternoon... along with the millions of cell phones ringing as the bosses read this...
Karma Whoring for Fun and Profit.
I strongly suspect this code doesn't do what it says on the tin.
Phew, lucky I run MS Windows then !!
"But see, Linux sucks! It has holes just like Windows does!"
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.)
Breaking Into the Industry - A development log about starting a game studio.
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.
Which reminds me, have you done your emerge -abuop6QvvvvVVvVVxz world yet today?
The average home user that's not willing to put in the effort to compile a new kernel is the home user that doesn't have anyone but either themselves, or people with physical access to the machine using it.
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...
The proof-of-concept code only supports x86 and x86_64. Does that mean other architectures are immune?
Inaccurate. It does require shell access, but it does not require it to be physically local.
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.
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
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.
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
You've got to be kidding me right? Like every sysadmin out there is supposed to know about every feature he doesn't use? Most of the time if you compile out something you'll end up breaking something you do want because you don't understand the internal kernel dependencies or what this really means in terms of functionality. Don't forget I now expect you on duty 24/7 to compile new kernels whenever there's a kernel patch available, particularly when you're sick and or vacation and whoever is filling in for you only knows apt-get/yum/whatever. Anyone that spent that much time on managing a Linux server would probably be fired because he'd be less efficient than a Windows server and an MSCE.
Live today, because you never know what tomorrow brings
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
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).
"I was in love with a beautiful blonde once, dear. She drove me to drink. It's the one thing I am indebted to her for."
PHBs aren't stupid (err.. did I just write that??). They understand that crap happens. They're not on your back because it happened, they want to know what you're going to *do* about it.
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.'
I get the impression the 'custom kernel' brigade have never worked on a corporate environment.
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.
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.
Quick, cue the Linux apologists! Damage control! Spin it! Only noobs and bad administrators would be affected!
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?
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).
Quo usque tandem abutere, Nimbus, patientia nostra?
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
vmsplice exploit fix
Have you got your LWN subscription yet?
...I have a question for you. I 100% agree this is an advantage of open-source than closed-source software will never have, ever. You've got me on that one, but my immediate thought was "ok, how much would I like to change my own kernel in production systems? About 0% thank-you-very-much".
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.
throw new NoSignatureException();