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.

Beauty of OSS

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.

Re:Beauty of OSS

And even if it isn't on its way (and while it isn't here) you can still get the source and remove the problematic part if you don't need it. Try recompiling Flash or some other commercial software without the section that has the exploit in ;)

.

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:Beauty of OSS

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.

Of course, the problem may also have been known six months ago. Not that that differs from closed source, but I don't see the openness of the code as a particular benefit in this case. The real benefit seems to be that when someone releases something as open source and they put their name on it, they're more inclined to be responsive to problems and provide quick fixes than when it's just some company's product and the developer's reputation is shielded by the company.
 

Re:Beauty of OSS

Looking at the comments at the top of the code, it's described as "quite old code" (assuming you believe the author).

Re:Beauty of OSS

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.

Or already here...
This appeared to work... [gmane.org]

Re:Beauty of OSS

The problem is now known so I'm sure a fix is already on the way.

Holy shit, no kidding - the form of an exploit which fixes the bug live in the kernel mem.
nobody$ ./exploit
[..]
[+] mmap: 0xb7f29000 .. 0xb7f5b000
[+] root
root# ^D

nobody$ ./disable-vmsplice-if-exploitable
[..]
Exploit gone!
nobody$ ./exploit
[+] mmap: 0xb7f34000 .. 0xb7f66000
[-] 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 /proc/kallsyms) and replaces the first byte with a RET instruction
(using mmap of /dev/kmem)" from
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953#14 [debian.org]

The sound you hear...

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...

jessica_biel_naked_in_my_bed.c ?

I strongly suspect this code doesn't do what it says on the tin.

Re:jessica_biel_naked_in_my_bed.c ?

Thats because you are compiling it with the wrong target.

You need to include justin_timberlake.h and link it with the millionaires library.

Re:jessica_biel_naked_in_my_bed.c ?

realdoll_and_a_tube_of_lube_on_my_inflatable_mattress.c ?

Thank God

Phew, lucky I run MS Windows then !!

Re:Thank God

That's like finding out there's a new 24-hour flu going around, and thanking God the AIDS will kill you first.

Re:Thank God

Phew, lucky I run MS Windows then !!

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.

Before the inevitable occurs:

"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.)

Re:Before the inevitable occurs:

The difference is that we know about this hole, and can now fix it

We know about it now, but how long have some other people known about it? There's this quote from the code:

This is quite old code and I had to rewrite it to even compile.

Is this x86/x86_64 only?

The proof-of-concept code only supports x86 and x86_64. Does that mean other architectures are immune?

Funny comments :)

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).

"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, ..." [last for four words utterly incomprehensible :)]
"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 :)) 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*.

This workaround works

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953 [debian.org]

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:Misleading

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.

Re:Misleading

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...

Re:Misleading

Yet another good example of why you shouldn't hire the sysadmins who blindly use what the vendors ship

I suppose. But honestly, not everybody really needs a sysadmin that's going to diddle around for weeks and compile kernels just to set up a mail server and samba, for example. For most things, I'd rather have someone who just gets the work done rather than goofing off compiling kernels, installing ReiserFS and doing god knows what else other than things that really matter. Sure, there's a place for all that, but honestly most environments don't require it.

Re:Misleading

This is not an universal problem. It only occurs for those kernels with a specific function compiled in that most installations won't need, and which halfway decent sysadmins won't have as part of the kernel anyhow when they don't need it.

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.

Which reminds me, have you done your emerge -abuop6QvvvvVVvVVxz world yet today?

Re:Misleading

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.

Re:For those that would rather write than read.

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.

Re:I am so depressed ...

Uh oh. There's another link, (not the one from the /. article) that worked on my machine:

http://www.milw0rm.com/exploits/5093 [milw0rm.com]

Notice the original article links to 5092.