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?
For me personally, I sleep well at night knowing that I run Opensource OS'es at home and at work. What about you? I for one do not trust that the money a commercial OS costs give me peace at mind with respect to security.
Thomas S. Iversen
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.
If you read the report, you'd know that someone must be logged into your machine in order to use the exploit. Secondly, you'll notice that /usr/bin/newgrp must be setuid root and world-executable. Additionally, newgrp, when run with no arguments, should not prompt for password." Maybe it's time we looked at how newgrp is set up. Secondly, by default in my distros, this is not the case. Go ahead. Try typing newgrp as a normal and see if it works. Now, if that's not the case, a simple chmod of newgrp will fix you right up (very few systems i suspect require newgrp be used from the point of a local user.)
"In order for this flaw to be exploitable,
Geez... I suppose if you make the useradd (or adduser) command world executable, make your shadow password list world readable, and then make a guest account on your system open to the public, then you too can have an insecure system!
The point is, at least for the second exploit mentioned in the mail, that unless a admin has set world-executable permissions on files to which only root should have such access, then this problem shouldn't exist. As others have said, its not like some random person out there can do all this stuff remotely to your box!
In case of fire, do not use elevator. Use water!
Oh well, looks like the boys at RedHat are gonna be putting in some overtime this weekend.
We released updated kernels yesterday:
Any good University setup doesn't allow regular users login-level accounts on critical servers. Students should have accounts on lab machines, and servers used for remote access, email, etc. but not on the web server, database servers, etc. While you may think that your ability to logon to the the "server" is a great honor, realize that the only use for that server is so people can login remotely to a common machine, the real servers are (or should be) locked up real nice like.
Mad Software: Rantings on Developing So
As it happens, *I'm* a sysadmin for a university.
If you think students have login accounts on our
database servers, you are frickin' insane.
Students get accounts on the academic systems,
which are set up solely for them to play on.
They are not let into the administrative systems
that actually run the school; we keep tight
control over who gets to log into those.
Chris Mattern
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
It's actually a kernel bug, and I'm told that any suid binary can be a vector. The temporary fix is to chmod -s all suid binaries on the system until it can be properly fixed.
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
Only on the assumption that this is your only world-executable suid binary. If you've any others, they're also vulnerable. To check:
cd /
find . -perm -4001 -uid 0
(this isn't quite complete - if you had a file which was suid root, owned by a non-root group and group-executable, that would also be vulnerable)
PenguiNet: the (shareware) Windows SSH client
I am sure Alan Cox will deliver a 2.2.20 soon, as he is still in charge of maintaining the 2.2.* kernel series. I saw a while ago an 2.2.19-ac*, but Alan has not been in a hurry to reach 2.2.20. But now, he definitely will be.
--- guns don't kill people, people with guns kill people ---
There were some benchmarks posted recently, but I seem to recall that the subject lines weren't particularly "on topic." Makes them harder to find.
In the meantime, here's one post..
Success report..
aah.. here's the one I was thinking of:
VM benchmarks..
This article appeared on stepwise.com, a site devoted to Mac OS X (so yes, Macs *are* vulnerable!") http://www.stepwise.com/Articles/Admin/2001-10-15. 01.html
[posted 18-Oct-01]
>>
Mac OS X 10.1 Local Security Exploit
A serious security exploit has been found in Mac OS X 10.1 (in fact, as it turns out, it has been present in 10.0.x versions as well). Using this exploit any user at the Desktop can gain root access to the machine.
The problem is caused by applications that are set-uid root (that is, regardless of the user that runs them, they have root permissions). Normally these programs have a limited scope of functionality so that damage is minimized. However, it appears that any items launched from the Apple->Recent Items menu inherit the root user privileges. Additionally, any other apps in the Apple menu (i.e. System Preferences) can be launched as root using this hole.
This can be demonstrated using the following technique:
[See URL above for more details]
So obviously, Linux isn't the only one that has these kinds of problems. And to that thread commenting about Mac OS not having problems like this -- yes, that might be true for Classic Mac OS, but its obviously not true for the current OS
Every OS that I've used in the past couple of decades has had some kind of "local security exploit". That's just the way it is.
Later,
--Gregory