Slashdot Mirror
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!
Additionally the 2.2 'superstable' series are also vulnerable. Better get out those patches on multi-user systems and be snappy too. Don't want to look like an M$-admin now do we? :D
Karma? what's that again?
Karma? What's that again?
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.
In case many of you don't subscribe to bugtraq, there was a follow-up posted to the original advisory. I have replicated it here for your convenience. It raises an important issue, suggesting that kernels up to 2.4.12 may be affected as well. I don't claim to know, just forwarding the facts. Note that, he is using a patched kernel which could introduce any number of flaws, but I'm willing to give him the benefit of the doubt.
/* begin shell session */
./epcs_ptrace_attach_exploit
/* end shell session */
Original Message:
From: Demitrious Kelly
To: bugtraq@securityfocus.com
Subject: RE: Flaws in recent Linux kernels
The description of the second problem is accurate, but I don't think the
assessment of the kernels which can or cannot be affected by this exploit
is... I'm using a newly compiled kernel Linux 2.4.12-grsec-1.8.3.
( Linux 2.4.12 with the Grsecurity Patch
http://www.grsecurity.net/features.htm )
#
[12:52:11][apokalyptik@home:~]:
bug exploited successfully.
enjoy!
sh-2.05$
#
Because you need root privileges to change the real group ID of a running process to an arbitrary group (therefore suid) and arbitrary users may wish to run it (therefore world executable)? You're not confusing it with addgroup, are you?
Huh. Lookit that. The "boys at Red Hat" put out an update before this story even appeared on Slashdot.
And I think you're seriously underestimating Mr. Torvalds.
Does this mean if you have a shell account on the server that this exploit can be used?
Yes.
If this exploit is run, can it be traced back to the user who ran it?
If process accounting is being used, yes. On the other hand, the user could just "fix" the logs after gaining root.
Does the ptrace command come installed as default on all distro's?
It's a system call, not a command, so yes - it's part of the kernel.
Oh well, looks like the boys at RedHat are gonna be putting in some overtime this weekend.
We released updated kernels yesterday:
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.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
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).
(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.
If God gave us curiosity
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.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
You should not have world exec programs set suid
/etc/passwd world writeable, let normal users construct their own IP packets and so on. Removing functionality in the name of security is not an acceptable option, especially when the functionality is this basic.
This is plainly not true. Programs like newgrp (and passwd, chsh, chfn, login, ping, su and others) require root privileges but are there to be run by users. The alternative is to either remove huge swathes of functionality or let arbitrary users switch their UID without any sort of authentication, have