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

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

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

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.

[etymxris]

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

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

Re:Beauty of OSS

[Anonymous Coward]

Wow... 3 posts before some twat turned it into a platform for bashing Windows.

Pretty good. That's 2 more posts than I expected when I read the headline...

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

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

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?

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.

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

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 [slashdot.org] - 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 [slashdot.org] -- Turns out to be FUD.
3. OpenBSD Will Not Fix PRNG Weakness [slashdot.org] -- 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 [slashdot.org] -- The summary makes it sound as though this affects Ubuntu, but later on we get this post [slashdot.org] 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: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: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: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: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: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: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.

Re:This is incorrect

[Anonymous Coward]

Somebody give this man some Karma, as this thread is turning South rather quickly with bad information....

Re:Beauty of OSS

[fd0man]

Oh, really?

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

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.