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.

Comments

Beauty of OSS

[bigtomrodney]

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

[IBBoard]

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

[dotancohen]

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 ;) Well, you could always just enter a blank CDR in the drive. I'd say that's about as close as you are going to get to "remove the problematic part" from Windows.

Re:Beauty of OSS

[nacturation]

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

[RonnyJ]

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

[fuzzix]

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

Re:Beauty of OSS

[Anonymous Coward]

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

Re:Beauty of OSS

[Anonymous Coward]

The smugness of these OSS fanboys just makes me want to use Windows ME so badly.

And smack them in the face.

Re:Beauty of OSS

[larry bagina]

that's the drawback of a monolithic kernel. You need to recompile to add or remove offensive parts. And those offensive parts aren't sandboxed.

Re:Beauty of OSS

[raynet]

Though you can compile many parts as modules and add or remove them at will.

Re:Beauty of OSS

[caluml]

I don't think I'm the first of us to say "Ah shit". No, you are, you really are! Google confirms it!

Your search - "Ah shit" - did not match any documents.

Re:Beauty of OSS

[Raideen]

And **how** in the world can you be sure that the thousand of users using this versiuon kernel:

1) Know about the bug

2) Can change/recompile the kernel

3) Even know what a compiler is

4) Even care to fix it thinking about "I'm using Linuzz, I'm invencible"

That's the beauty of close Source. One Live Update service to fix them all. Not trolling. Just not everything is black and white. There are a LOT of shades of gray there in between.

The truth is that you can't. The thing is that you don't have that guarantee with closed source either. The difference is that open source gives a lot more options to those who can and even those who can't (by virtue that someone who can can supply a pre-compiled fix). Open source isn't perfect. It just has some serious advantages in this particular type of situation.

Re:Beauty of OSS

[colmore]

Any programs run by a normal user will be run in "normal user mode." The exception being suid programs, which are few and far between (and aren't things like webbrowsers). As to code on my system using a malicious exploit, especially one that has made headlines? Yes, I do trust packages from Debian enough to be fairly certain that those in the stable repositories are that safe.

See, we don't download binaries from websites and click "yes" until the installer shuts up. (Though I hate to say it but there are some utilities and install scripts coming out of the Ubuntu community that are dangerously close to that kind of installation paradigm.)

Re:Beauty of OSS

[myowntrueself]

disable-vmsplice-if-exploitable causes kernel oops on Debian Etch with kernel 2.6.18-3-xen-686

Re:Beauty of OSS

[smittyoneeach]

Did you follow http://www.milw0rm.com/exploits/5092?

Allow me to past in the first couple of lines:

/*
* jessica_biel_naked_in_my_bed.c
*

Apparently, milw0rm does have a patch for that.

Re:Beauty of OSS

[LizardKing]

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:

while (exploitable) {
Bricks *bricks = malloc(sizeof(Bricks));
shit(bricks);
sleep(1);
}

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

[Morten Hustveit]

disable-vmsplice-if-exploitable causes kernel oops on Debian Etch with kernel 2.6.18-3-xen-686

Did the exploit work by itself? It would be interesting to know whether the exploit or the workaround crashes the machine. The exploit (without my patch) is known to crash some machines.

Re:Beauty of OSS

[myowntrueself]

Did the exploit work by itself?

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

[Slim Backwater]

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

Re:Beauty of OSS

[petermgreen]

Normally the browser would only have access as your user account,
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.

Re:Beauty of OSS

[FliesLikeABrick]

What are the downsides/risks of using that fix/workaround? What functionality does it break or restrict?

Re:Beauty of OSS

[Dan Farina]

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

Re:Beauty of OSS

[fd0man]

Oh, really?

Did you forget about assignment versus equality, perhaps? http://kerneltrap.org/node/1584

Re:Beauty of OSS

[Isauq]

Funny you should mention that. This bug was fixed in a commit yesterday afternoon (http://lkml.org/lkml/2008/2/10/8).

Re:Beauty of OSS

[XenoPhage]

So while it may not be difficult to spot some wayward code if you are a geek, it might not be if you are a 65 year old hippie who knows almost nothing about computers. What does RMS have to do with this?

Re:Beauty of OSS

[Alex Belits]

You can shit null pointers, too.

Re:Beauty of OSS

[Joe the Lesser]

If it fails then he dumps core, which may be an acceptable alternative.

Re:Beauty of OSS

[Daniel Phillips]

Looking at the comments at the top of the code, it's described as "quite old code" (assuming you believe the author). I believe the author, but I think he was referring to the boilerplate exploit code, which is pretty awful code to tell the truth. The vmsplice bit looks brand new to me, but who knows, perhaps somebody out there really did know about the hole for the last year and a half. If so, they kept it to themselves and damage was not widespread.

The sound you hear...

[downix]

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 ?

[Anonymous Coward]

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

Re:jessica_biel_naked_in_my_bed.c ?

[LiquidCoooled]

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 ?

[BJH]

realdoll_and_a_tube_of_lube_on_my_inflatable_mattress.c ?

Thank God

[Zoxed]

Phew, lucky I run MS Windows then !!

Re:Thank God

[Anonymous Coward]

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

[monkeySauce]

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.

Re:Thank God

[Anonymous Coward]

You'll get used to it.

Misleading

[arth1]

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.

Re:Misleading

[shadow42]

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

[Unoti]

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

[fo0bar]

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

[Anonymous Coward]

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

[pak9rabid]

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.

Re:Misleading

[Kjella]

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

[MikeUW]

If I end up with a locally installed root kit on my laptop, I'll only have myself to blame. For some reason, though, I lack the motivation to recompile the kernel to protect myself from myself.

Re:Misleading

[kitgerrits]

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

[Tony Hoyle]

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

Re:Misleading

[arth1]

I think that after spending man-months on getting the equipment installed in the first place, spending an extra man-day on proper configuration would be a good investment.

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

[arth1]

Could you go into any detail into why most installations don't need this particular function?

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.

Even if you can, it's hardly misleading to call it a 'Linux Kernel 2.6 Local Root Exploit' if it is one, is it?

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.

Re:Misleading

[BasharTeg]

Quick, cue the Linux apologists! Damage control! Spin it! Only noobs and bad administrators would be affected!

Re:Misleading

[Actually, I do RTFA]

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.

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.

Re:Misleading

[arth1]

No, you won't. If you have a problem, you reboot a lab server to a standard kernel, verify that the problem is there, and report it. RH has no problems with that, as long as you can replicate the problem on a vanilla system.

Re:Misleading

[Teppic_52]

You know, I haven't built my own kernel since 'make menuconfig' was the most advanced method around.
I thought it still was...

Re:Misleading

[Neoprofin]

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.

Re:Misleading

[iabervon]

Using vmsplice() in ordinary applications should improve system performance under load when appropriate (when you send full pages of generated data to a network connection, the kernel won't have to copy the pages, it can DMA straight to the NIC, saving work and cache space). So it's quite possible that distros would ship binaries that use vmsplice() if their default kernels support it, and it would be a performance hit to disable it. I don't know if any significant programs actually use vmsplice() yet, but it wouldn't be surprising.

Re:Misleading

[Penguinisto]

You'll find that you no longer have the time to check SANS and packetstorm every day

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

/P

Re:Misleading

[caluml]

Care to say, *which option* should we disable in the kernel .config ? Good question. I, from what I can see, don't think it has an option that you can disable. I just edited /usr/src/linux/fs/splice.c, and changed the line (round about line 1200-ish - differs slightly) from

if (unlikely(!base))

to

if (!access_ok(VERIFY_READ, base, len))

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.

Before the inevitable occurs:

[ZorbaTHut]

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

[RonnyJ]

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.

Re:Before the inevitable occurs:

[moderatorrater]

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.

Re:Before the inevitable occurs:

[QuantumG]

Yeah, this is an example of one of the millions of Linux kernel holes there are out there. Every now and then, a blackhat gets a job and wants to impress his employer so he pulls out some of his old code and polishes it up. You can tell when it happens because they are so childish that they make the exploit trivial to demonstrate and distribute it far and wide. And you just know that every blackhat who had a variant of this exploit in their personal collection are like "well thanks asshole, now I've got one less Linux kernel exploit.. bastard."

Re:Before the inevitable occurs:

[Anonymous Coward]

>One advantage that a large paid organization can have is strict testing requirements

As opposed to Linux, which is backed up by several large paid organizations, notably including IBM.

Works for me too

[etymxris]

Just tested on Suse x86_64 10.3, ran as local user and it dropped me into root.

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

Re:For those that would rather write than read.

[McDutchie]

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:For those that would rather write than read.

[etymxris]

Well if you have a shared hosting account that allows ssh logins, anyone can now become root and start messing around.

Is this x86/x86_64 only?

[the_humeister]

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

Re:Is this x86/x86_64 only?

[cnettel]

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.

Re:Is this x86/x86_64 only?

[Zoxed]

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

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:Is this x86/x86_64 only?

[EmbeddedJanitor]

The POC code needs to have different alignments for x86 and x86_64 but that in itself does not mean that the same concept could not be used to break other architectures, (eg. ARM which probably runs the majority of Linux systems out there... all the phones etc).

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.

Re:For those that would rather write than read.

[tabrisnet]

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.

Funny comments :)

[K. S. Kyosuke]

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

[FliesLikeABrick]

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.

Re:This workaround works

[FliesLikeABrick]

I should say.. the ubuntu machines I tested it on do not appear to have vmsplice enabled. YMMV.

Re:This workaround works

[Tony Hoyle]

The parent bug for this is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464945

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

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:This workaround works

[Pecisk]

To answer to myself, tried exploit on Feisty, doesn't work (segfaults). Not sure about Gutsy or Hardy yet.

Re:This workaround works

[arabagast]

Ubuntu 7.10, latest generic kernel image (standard image) is affected

Linux kenshu 2.6.22-14-generic #1 SMP Fri Feb 1 04:59:50 UTC 2008 i686 GNU/Linux

Neat, but...

[kickmyassman]

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

Re:I am so depressed ...

[Cytlid]

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.

This flaw is CVE-2008-0600

[iamamoose]

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

Re:This flaw is CVE-2008-0600

[icydog]

This worked on my Fedora box both locally (i.e. keyboard) as well as through SSH. However, it did NOT work on my CentOS 5 installation. The box locked up hard and now I have to call someone to reboot it... silly me...

where to find in menuconfig

[FudRucker]

is vmsplice part of virtualization found in Device Drivers > Virtualization (and the submenu within the said location)?

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?

Re:ssh

[walt-sjc]

Well, if you are running machines that are designed to be enterprise class, it isn't a problem. Remote console is standard on enterprise class hardware.

Re:But this can't be real!

[SwashbucklingCowboy]

For example - when it's gonna have a real filesystem with name/file (or inode if you like) separation?

NTFS has had that for a while now.

Or ulimits? Will Windows ever have those? How do you even run any real server without ulimits?

Suggest you check out Windows System Resource Manager

The real problem here seems to be not Windows, but your ignorance about Windows.

SELinux?

[Rob Riggs]

Well, I can tell you that SELinux (enforcing, targeted) on Fedora 8 was no help in preventing this exploit. Does "strict" make a difference?

yea but how do we disable it till its fixed?

[Narcocide]

Pardon me for the rookie question - but can anyone tell us which kernel config option enables this so-called vmsplice? I'm no even clear on what its for... if its something I don't need can I disable it through menuconfig or is it something that I'll need a patch to disable?

'Sploit needs fixing on x86-64

[L. J. Beauregard]

The given exploit prints pointers using "%lx". That's wrong, and on x86-64 it will break (pointers are 8 bytes, longs are 4 bytes).

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:'Sploit needs fixing on x86-64

[Kirth]

Not only there:

$ 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 undeclared identifier is reported only once
jessica_biel_naked_in_my_bed.c:211: error: for each function it appears in.)

$ gcc -o 27704-2 27704-2.c /tmp/ccJWJWBA.s: Assembler messages: /tmp/ccJWJWBA.s:156: Error: Illegal operands /tmp/ccJWJWBA.s:156: Error: Unknown opcode: `andl' /tmp/ccJWJWBA.s:156: Error: Illegal operands

Bloody x86-asm. Doesn't work on Sparc.

Re:'Sploit needs fixing on x86-64

[Sinical]

No, only Windows uses the retarded long/4 pointer/8 on 64-bit. Linux correctly has 8 byte longs and pointers for x86_64.

#include

int
main(int argc, char *argv[])
{
        printf("%lu %lu\n", sizeof(long), sizeof(void *));
        return 0;
}

$ gcc -Wall test.c -o test
$ ./test
8 8

I agree that %p would be the better choice, but using '%lx' should only provoke warnings on a 32-bit distro.

Re:Whatever...

[jacksonj04]

Tell you what. I'll go off and compile a kernel with lord only knows what packages and options enabled and disabled and spend days fine-tuning every last cycle out of some obscure feature, then drop it on your desk and tell you to upgrade something. 12 hours later, when you're cursing it for refusing to compile because I altered some bizzare dependancy which nobody in their right mind would recompile --with-extended-range-bypassing-support-mode-library-retrograde, come to me and I'll tell you you're a mindless drone.

Far more sensible in a corporate environment is to stick to the published stuff, so when it goes tits up you can call support and say "Fix it", or when your sysadmin leaves the incoming guy doesn't have to work out why the server is configured to behave in a way which "will be really great" but actually means everybody's mail is delivered in Swahili.

Re:HA HA

[TheVelvetFlamebait]

No it doesn't.

slashdot not filtering well enough

[bcrowell]

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:

1. Adobe PDF Exploits In the Wild - IMO this was not sufficiently well thought out to be useful. There has been a long series of problems with AR related to the fact that it allows javascript in pdf files to be executed, and that leads both to privacy problems (authors can track readers) and security problems (buffer overflows). But the article didn't specify whether it was such a problem. If it is such a problem, then the correct solution is to disable js in AR. In fact I'd already done that in AR 7, but if I'd blindly followed the advice from the article, here's what would have happened. I would have just upgraded to AR 8 and assumed the problem was fixed. But upgrading to AR 8 reenabled js, so in fact I'd be less secure than I'd been before.
2. Serious Vulnerability In Firefox 2.0.0.12 -- Turns out to be FUD.
3. OpenBSD Will Not Fix PRNG Weakness -- Possibly of interest to openbsd users, but basically what seems to be happening here is that each BSD's maintainers are making their own judgments about how serious the problem is, and the seriousness of the problem is a complicated and controversial question.
4. Linux Kernel 2.6 Local Root Exploit -- The summary makes it sound as though this affects Ubuntu, but later on we get this post pointing out that it doesn't affect a default install of Ubuntu.

This is really getting to be a Boy Who Cried Wolf thing.

Re:slashdot not filtering well enough

[DCBoland]

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

Just fixed it.

[nagora]

Read the bug, ran Vi, fixed exploit in Try that next time your Windows machine has an exploit.

That's why I use an open-source OS. I can fix it when it breaks.

TWW

Re:Just fixed it.

[DarkProphet]

Maybe you should try using EMACS to post on slashdot instead. *ducks*

Re:Whatever...

[Tony Hoyle]

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.

Re:I am so depressed ...

[Cytlid]

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

Ubuntu 7.10 generic kernel is affected.

[ikarous]

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.

Re:For those that would rather write than read.

[caluml]

I have tested the exploit on a Linux VPS box within a VPS as a standard user, and it didn't work. Not sure if this is luck, kernel config, or good VPS design (Hello Bertl!), but either way I am happy.
/me will start using GRSec again. It might not stop/have stopped this (I have no idea), but it's just an extra layer of difficulty.

Re:I am so depressed ...

[nuclear_zealot]

I got the same thing, so I edited the one line: (brackets edited out)

#include asm/page.h to read:

#include /usr/lib/klibc/include/asm/page.h and *poof* the exploit compiles and works on my 2.6.24 x86_64 box. Don't feel safe yet. :)

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?

2.6.24.1 is Not Vulnerable

[iive]

Here is the first entry in the latest kernel ChangeLog-2.6.24.1 http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.24.1

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.

Re:2.6.24.1 is Not Vulnerable

[bconway]

That is incorrect. There are three different vulnerabilities here, you're only accounting for one of them.

This is incorrect

[bconway]

Vmsplice is part of the core kernel, it is not a configuration option. It is used all over the place.

Re:This is incorrect

[Vertigo Acid]

RTFS?
2.6.14.7 does not fall within the affected range of 2.6.17 to 2.6.24.1

Re:But...

[Mr. Roadkill]

I, for one, trust myself and am the sole user of my heavily-password-protected computer. Looks like I'm fine, and it sounds like the easiest solution in a private setting to me.

Indeed, it's only exploitable if someone can get at it. If you don't offer any services whatsoever to the outside world, then you should be okay.

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

[Wakko Warner]

Thankfully, nobody runs Linux on enterprise-class hardware.

Re:HA HA

[Anonymous Coward]

+--------------+
|    PLEASE    |
|    DO NOT    |
|   FEED THE   |
|    TROLLS    |
+--------------+
      |  |
    .\|.||/..

Ran the fix, couple of notes...

[brassman]

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.

Last resort from a cracker?

[gringer]

From what this looks like (given the "old code" comments, and timing of the release of exploit code), I'd say that someone realised that their pet root exploit was being patched in the current kernel (2.6.24.1), and wanted to have a final go at increasing the impact of the exploit before it was snubbed out. I find it hard to believe that, coincidentally, they just happened to post this exploit on milw0rm the day after the change appeared in the kernel.

Poor form, but I guess it has at least made a few more people aware of the severity of the issue.

The patch. Everybody needs this.

[Daniel Phillips]

vmsplice exploit fix

To everyone saying "I ca fix it myself"...

[Toreo asesino]

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

Re:fast response

[pclminion]

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

Source of Mystery Malware Affecting Linux/Apache?

[Spoke]

This local root exploit is very likely to be the one used to infect servers reference in previous Slashdot article Mystery Malware Affecting Linux/Apache Web Servers.

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!