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?

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

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.

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.