Local Root Hole in Linux Kernels

xepsilon writes "A local Linux security hole using ptrace has been discovered that allows a potential attacker to gain root privileges. Linux 2.2.25 has been released to correct this security hole, along with a patch for 2.4.20-pre kernels. 2.4.21 ought to contain this fix, once it is released. 2.5 is not believed to be vulnerable to this security hole. See this email from Alan Cox for details, and a patch."

Comments

Re:Eek!

[dreamchaser]

New marketing ploy for TMF: get your security news before the 13-year-old 5

Not so fast! What if they steal some CC numbers first?

Re:This has to be erroneus.

[Anonymous Coward]

Perhaps a better question to ask would be "Would this bug have been discovered had the source not been open to the public?"

Don't forget us 2.0.x users.

[Anonymous Coward]

It may be old, but it's still useful.

Noone ever said Linux/BSD is perfect

[nurb432]

But at least they admit it when there are problems. As does the BSD crowd too.

And *nix is still a hell of a lot closer to perfect..

Re:Time to patch my IIS^H^H^HKernel

[suicidal]

lol
Too bad this was only exploitable locally. Any secure server would not have local access available to users. I have to agree, but not as a zealot. Bugs will happen but Linux development seems to have them patched instantly, whereas Microsoft's ploy is play dumb until the patch is released, and then act like they did it overnight.

I'm not going to patch.

[gosand]

Soooo, i wonder how many posts will appear here along the lines of those in the WebDav exploit story earlier. Not many im willing to bet. Those people willing to shout and hollor at every serious issue, screaming bloody murder because someone got it wrong, really pisses me off. Yes people get it wrong, they write insecure code from time to time. This issue and a number of those before it show that Linux has as many opportunities for exploitation as any other OS.

I hate when I choose to reply instead of mod, but this needs to be said - they aren't the same!

I am not going to patch my Linux systems. Why? Because it isn't possible to exploit this vulnerability remotely. The only local user on my machine knows the root password (me). So it isn't quite the same severity as a bug in a widely distributed webserver. Yes, they are both serious, but compare apples to apples. (not that your comments aren't correct, just that you need to make them at the right time.)

Re:I'm not going to patch.

[siteTHREE]

Have you considered the possibility of someone exploiting a non-root remote hole on your box and now having the ability to escalate themselves to root?

Re:I'm not going to patch.

[Havokmon]

Have you considered the possibility of someone exploiting a non-root remote hole on your box and now having the ability to escalate themselves to root?

EVERYBODY plays the odds:

FIRST: a user has to exploit *A* remote exploit. Which one? Could be anything. Most exploits are either popular services, or shots in the dark. Patch the popular services, and you've defeated 90% of the scans. Remember, there's safety in numbers, and the vast amount of hosts on the internet just makes it less likely you'll even been scanned in the first place - and even less likely that your exploitable remote hole is discovered... (But, yes, definately patch outside services)

SECOND: As a cracker, once you've got that local exploit, what root exploit do you try and take over? Granted, you may have an unlimited amount of time to scour the system for vulnerabilities, but unless that system is actually WORTH something to you, you'll just move onto something easier.

Ease of use, it's the American way. Sure, you may say it's security by obscurity, but deadbolts are EXACTLY the same thing. Any idiot can break down the door or pick the lock.. it's just easier to get into a home with a door that's already open.

Re:patched it already

[sporty]

The only reason not to update, is if you haven't QA'd (burn in test) your new kernel. Put int through 100% load tests for 24-48 hours to make sure nothing goes haywire. Last thing you'd want is a strange memory leak causing processes to go bezerk.

Not to say that you haven't done that, but buyer beware. It makes no diff if it were linux, mac os x , windows, commodore 64. Don't randomly update things. Heck, sometimes us programmers create bugs in programs that are fixed by other bugs existing. Closing one may expose a new one.

Dangit, Slashdot, mirror things like this

[Kiwi]

Dangit, Slashdot, mirror things this important; don't just link to some poor low-traffic Linux kernel archive which can not handle Slashdot-level traffic. I normally don't mind sites being Slashdotted, but a critical security fix being slashdotted is not a good thing.

Anyway, another copy of the patch.

- Sam

Re:patched it already

[ignipotentis]

And the difference between this and setting Windows Update to download automaticlly then inform you before proceeding with an install is? Basically all that has been proved is a good admin will stay on top of updates. And eveyone here gets confused when something isn't Microsofts fault.

Common misconception

[burgburgburg]

With so very many vulnerabilities (and ever expanding), it's easy to see why you'd assume that Windows was the only buggy vulnerable bloated operating system. This isn't true. It just seems that way. It feels that way. And, considering how wide rangingly destructive Windows vulnerabilities tend to be, for all intensive purposes, it is that way. But, deep down, we all acknowledge that it isn't technically true.

Troll: Arrest Alan Cox!

[Anonymous Coward]

Obviously the kernel provides access control to a copyrighted work (the Linux kernel, and all apps on the system). Therefore by providing this info, he is disseminating a mechanism to bypass said access control. Therefore he is in violation of the DMCA!

Go ahead an call me a troll, but he did say that's why he wasn't ever setting foot in the US again!

Linux auditing

[Kourino]

I think our friend Al Viro would have something to say about the auditing level of the Linux kernel. And if we're talking about drivers/ in particular, it would probably involve the words "obfuscated", "brain dead", "steaming pile of shit", "warped beyond all belief" ... :)

Linux code gets a fair amount of review. But once it's there, there really isn't any auditing at all.

this could be a big problem

[Trepidity]

Everyone's taking comfort in the fact that no remote exploitation is possible, but remember all those universities that you've convinced over the past few years to switch from proprietary UNIX to Linux for their cs department and mail servers? The ones with thousands of local accounts given out to all the students and faculty? Yeah, they might not be happy about this.

The Smaller Folks

[DarwinDan]

I second that opinion. However, many sysadmins have a responsibility for public servers (lots of ports open even with a firewall). As such these same sysadmins are smart and have a redundant box to do things like patch a system.

In addition, some small businesses don't have the luxury of a secondary box or even an IT specialist that can put a machine through a high-load test for more than a few hours at a time -- let alone having to patch it at all!

Ideally we would all have a RAID 10 array connected to four boxes each running a different OS. While some companies (!) may have the time and money for this, the small folks like mom-and-pop stores can't afford the expense of time or money.

UNIX to Linux switch

[aksansai]

Never forget that proprietary, commercial UNIX solutions are also vulnerable to kernel-level bugs and exploits. I used to work for a university that deployed Linux and Solaris solutions - the patch sets for Solaris (kernel and userland utilities) were just as necessary as the Linux server installations.

The beauty of the Linux and open-source worlds is that the code is available right before your very eyes and is subject to scrutiny, day-in and day-out. Commercial offerings are not available to the general public, potentially leaving behind bugs that wouldn't be caught by the few who _could_ see the code. Code that is viewed by literally thousands of all programming backgrounds, versus code that is viewed by a select few which only specialize in that code, is more likely to be exploit-free.

This particular Linux kernel exploit was encountered by developers that recognized the flaw. And, luckily for us, the developers were talented enough (or knew someone in the core development group) that could quickly produce a patch so that administrators could secure their servers from being taken advantage from.

If the exploit was encountered in the commercial arena, the person who found the flaw would have to contact the company who supports the operating system. An assessment team would have to see the cause/effect/consequences of the exploit. Then, the development group would have to produce a patch. The company would then contact their support group to contact their enterprise customers first (more than likely) to deploy the patch. Finally, with the company's core customer interests intact, the company would publish their findings and solution for the remainder of the world. Many Microsoft patches are first released to their core enterprise companies - and then released via Windows Update (or through their web site).

For universities that have made the switch, there should be more peace of mind knowing that the quantity of security breaches on the kernel level are much less than the overwhelming number of Windows flaws (which generally require a reboot) and at a much cheaper price than a commercial UNIX offering.

Re:Linux disclosure procedures?

[N3WBI3]

Of course I will test, but the testing almost always takes less time because it does not break other services. When we had to patch windows to avoid all the SQL server crap a while back it broke the damn server, so in testing there is going to be more tweaking involved than one might have with a typical Linux patch..

get over it--your local system isn't secure anyway

[g4dget]

Realistically, most regular Linux systems are not secure against local exploits: making a system secure that way is possible, but it's quite a bit of work. You certainly won't get such a system by just doing a [insert your favorite distribution] install. This isn't exactly news either--it's been like that for a long time.

Of course, it is good that these kinds of bugs get fixed. Some people do run multiuser systems, and it provides an additional barrier against intrusions. But don't lose any sleep over it.

Incidentally, these kinds of exploits are probably rampant on Windows systems; there, people don't even bother looking for them because there are very few multiuser machines and most people have local Administrator privileges anyway. Also note that Microsoft didn't even try to get Windows certified secure for multiuser use.

Re:patched it already

[caluml]

I would disagree.

I much prefer it the way it is. Take Apache/ IIS as examples.
If you're running 1.3.26, you're safe, and you know it.
With IIS, if you're running IIS5, but with patch X, and patch y, and patch z applied before patch q, unless you have the MSSql patch r installed in which case you need patch f for IIS, and patch k for MSSql...

They should do it the other way. Make it simple.
If you're running IIS 5.0.185 then you're OK. Anything else, and you've got problems.

Patches and stuff were OK during floppy disk days, and 28.8k modems. I'd much rather not have to worry about incrememental patches.

Re:To all the windows bashers...

[jelle]

Sure, both are security bugs, but of a totally different order of magnitude.

The IIS hole was a remote exploit including privilege escalation open to abuse by anybody on the Internet, and the kernel one was a local privilege escalation open to abuse by system users with shell access or other capability to run&abuse ptrace(). If you have untrusted local users, you should run them in a UML or vservers/ctx anyway so thay if they escalate privileges, they still can't harm the system.

Plus, the IIS bug was found after US ARMY web sites were getting hacked, and the kernel bug was found by a developer that was auditing/working on part of the code and patch available before any bad guy got to it.