Linux Kernel Bugs

Armin Herbert writes: "According to this mail from Rafal Wojtczuk and a german article on Heise Online, there's a new severe bug in all Linux Kernels, from 2.2.0 up to 2.4.10, which allows users to become root on your system. Kernel 2.4.12 fixes this problem, and RedHat, Caldera and other distributors already supply patches for their Kernels. See Bugtraq for more information." Important notes for anyone running a multi-user system. Update: 10/19 16:12 GMT by J : If I'm reading Nergal's writeup correctly, 2.4.10 is still vulnerable to the local DoS, but not to the local root exploit. Separate issues. And as pheared points out, there is one unverified report of a custom 2.4.12 being vulnerable as well; please try the exploit on your system and let us know what you find. This is a big one, you can expect the kiddies have already added this to their rootkits. Update your systems now!

Comments

2.4.12-ac3

[Defiler]

If you're going to run 2.4.12, I suggest adding the latest Alan Cox patch to it, as well as Rik van Riel's "hogstop" and "eatcache" patches.
First, start with the base 2.4.12 kernel: (Use a patch to save Kernel.org's bandwidth, if you have a recent 2.4 kernel lying around.)
2.4.12
Next, patch it up to 2.4.12-ac3:
2.4.12-ac3
Finally, apply these two patches to 2.4.12-ac3 to yield 2.4.12-ac3+hogstop+eatcache
Hogstop+Eatcache

This is currently the ultimate in Linux VM performance.

Re:sucks to be a guy named Torvalds right now...

[teg]

Oh well, looks like the boys at RedHat are gonna be putting in some overtime this weekend.

We released updated kernels yesterday:

• A 2.4 kernel, for Red Hat Linux 7.1
  
• A 2.2 kernel, for Red Hat Linux 6.2 and 7
  

Not quite

[radish]

NT boxes have different types of user. Sure, only one can be logged in at once, but an exploit which allowed a normal user to gain Administrator privilidges is _exactly_ the same as a local root exploit. And yes, these have existed in the past, and probably still do.

Work-around without rebooting (2.2 kernels)

[pp]

There's a loadable kernel module that
replaces the ptrace() function call with
a wrapper that makes it impossible to exploit
this bug. It can be found from
http://c.home.cern.ch/c/cons/www/security/.
Works on 2.2.19, not tried to use it with 2.4.x yet (should be pretty easy).

Re:"Only" a local root exploit

[Telek]

(I have to retype this comment because I got a "form keys error" while trying to submit the first one. I find it so ironic how the /. community continuously bashes MS for their stupid bugs and can't keep /. running for more than a week without some sort of error)

If you want to compare to Windows: up till Windows XP it wasn't even possible to be logged in as multiple users at the same time, so the equivalent of a local root exploit was not really possible.

Incorrect on both counts.

Since at least windows NT server 4.0 you have had something called Terminal Server which gave remote users the ability to log on to your server and run applications (and with recent incarnations it is in a manner much faster than xwindows too). Windows NT 4.0 (regular) also had the ability to run programs as different users (through a bit of a trick), and this trick was turned into a real feature in Windows 2000 with the "run program as a different user" option. Windows XP was just the first one to allow a logged in user to keep all of his programs running while he is "logged out". I had a utility that I used to run on Windows NT 4.0 called "su" (and you can guess what that does) which allowed me to run any program as a different user.

And besides, being able to have multiple simultaneous logged in users has no relevance to the ability to have root exploits. As long as you have user privilege levels you can have root exploits.

Re:Hardly.....

[tshak]

Name one exploit of late that was compromised (read: actual cases, not NTBUGTRAQ "COULD HAPPEN" reports) before M$ released a patch. Most all exploits occurred on unpatched machines when the PATCHES WHERE AVAILABLE well before the script kiddies got ahold of the exploit.

Now, don't get me wrong, some of these holes should be an embarassment to the respective development teams. Hopefully with XP and in the future Microsoft will step up on security issues from a software design level. However, from a response level, they are doing an incredible job.