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.

"Only" a local root exploit

[Baki]

Before screaming, please remember that this is only a local root exploit, that is you must already have logged in on the machine as non-root before using this exploit.

Most Unixes have had dozens of (sometimes known) local root exploits for years, and while most of them have been ironed out, some surely remain. They are much much harder to eradicate as exploits directed to network services (i.e. from the outside) are. Every once in a while one is discovered in most UNIXes (often obscure race conditions etc).

Till a few years ago the saying was that you should never give a local login to someone who you would not trust to be root, i.e. one could assume that sooner or later those that really try to become root shall succeed. Any mission critical servers should not have any user accounts for untrusted people; therefore, local root exploits have never been considered to be a big deal.

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. Still, Windows managed to have multitudes of the way more stupid and serious class of remote exploits. With the advent of Windows XP the concept Windows kind of becomes multi-user for the first time (though in a very crude way, since unlike UNIX/Linux each login session almost starts a new instance of larger parts of the operating system). While this new concept is 30 years old in UNIX, only now Windows (XP) starts having the possibility of local exploits. Surely many of them will exist and it will take decades to kind of iron them out.

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.

So, do we get a 2.2.20 from this?

[devphil]

Or do I need to deploy these patches myself? What's the policy for ass-nasty bugs in superstable kernels which have already reached their official end-of-development?

I may be wrong but...

[Kailden]

Somewhere deep inside the comments on both sides that start comparing linux to microsoft are missing the fact that most linux users are on average more technically savvy, expecially if they are connected to the big old net. So obviously, when linux announces a security hole a majority of users who are attached to the web get concerned and go out immediately and update thier system.

But when companies and home users are running a COTS that they prolly didn't even install and don't even no what say IIS is, they don't get real concerned about updating thier systems.

For an example, look at Code Red Infections that occured after the security hole had been announced.

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
  

Re:What is a Good Mailing List for this Info?

[teg]

Can someone recommend a good mailing list for linux issues? I am using mostly RedHat boxes, but they don't seem to have any free mailing list that I can find (perhaps they have one i don't know about).

Go to our mailing list server, and sign up for redhat-watch-list.

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.

2.4.12-aa1, or even better 2.4.12-pre3aa1

[On Lawn]

Hmmm, according to the LWN that you linked to, aa patches have the best performance.

For those that don't know aa stands for Andrea Archelangi who one of the very importent kernel hackers. It was a large part of his effort that stabalized the 2.2 VM. Although it is debated on which VM is better, over 90% of the benchmarks I've seen have pointed to AA being the better choice.

AC even mentioned that the AA-VM was the right way to go, just too wild of a change for a stable kernel series. There is too much conspiracy theory going on that AC is hijacking the kernel for RedHat, or that the RedHat crew has a not-invented-here phobia for not including the better VM.
Now on to a more editorial comment.

There seems to be quite a war on this right now, but I think it will settle down in about 6 months or so like the ReiserFS wars have. I also think that we'll see a new order established in the stabalizing of kernels.

I have no political say, but I expect that Linus will run a kernel that will be considered the "experimental, quicker evolving" kernel where things change violently. AC and others job will may to pull out pieces to salvage a semblance of stability, essentialy forking the stable branches from Linus's more exotic cutting edge kernel.

This seems to be how things run in any case when there is a developmental kernel, and they run pretty well. The question that may be asked is "Does Linus need to slow down his effort to stabalize at all?" Its arguably true that the answer is "yes", but only to a degree that suits his own needs for order in his life-long persuit of the sexy kernel.

Linus himself mentioned that AC does a better job of it, maybe its time to give him the whole forking-a-stable-kernel job.

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

[BMazurek]

You should not have world exec programs set suid, especialy on a system that you expect to be completely secure.

'Cause no local user ever needs to run passwd.

Or df.

Or ping.

Or xterm.

Or rlogin.

Or su.

Or top.

Or traceroute.

A completely secure machine is a painful thing to work on. Yes, it may be necessary in some circumstances. Banning world executable setuid programs is a securing technique, but it's not the blessed saviour you're making it out to be.

Parallels a situation many governments are facing right now: How much security do you implement to protect your population while still maintaining some semblance of freedom?

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.