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!
This happens all the time? When will people realize that Linux is inferior and unsecure. Everyone knows that open-source peer-review is a lousy tool for security-audits. No, why doesn't everyone run Microsoft products? They're completly secure and doesn't have any problems at all. Because that's the power of closed source.
Hope the irony isn't lost on you...
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?
I'm aware that the exploit is within ptrace and not newgrp itself but...
...the SecurityFocus notice uses newgrp as an example of a program from where the hole can be exploited and it states that most Linux distributions default with newgrp suid root and world-executable. Call me odd, but I'm not sure I understand why a sysadmin would want newgrp to be world-executable.
STOP MISUSING APOSTROPHES, YOU MORONS!!!
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.
Well it's not exactly a remote hole. The user still needs to have execute privs on the system they want to root out.
The "laughing" at MS's security holes isn't necessarily about how easiy it is for a user to gain administrative priveledges, but how easy it is for anyone anywhere to gain remote admin privs.
Not that I'm saying your comments are completely without merit; a hole like this should have been spotted sooner IMO (though I don't know how obvious it was). I'm also not blind to the fact that remote exploits have been found on Linux systems/services.
STOP MISUSING APOSTROPHES, YOU MORONS!!!
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.
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?
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
To all the people that feel really good about this because they are sick of microsoft being attacked about this: Good for you, you deserve it, enjoy because it won't happen again this year ;-)
;-)
Now to all the linux zealots here: To make sure that this doesn't become a problem we NEED to patch EVERY machine we can find and tell EVERYONE that has a linux box to patch it, why? because NOW it's funny, there isn't a worm out with a remote exploit of GPM that triggers an error Identd to give away your "Games" password so you can log on and become root
but we must make sure that this disappears ASAP or else this sure as hell won't be funny anymore. PLEASE make sure that we won't get staroffice macro virusses, sircam 4 linux etc... THAT we will be the laughing stock of the entire software world... I'll bet that microsoft competetion management (r) is already producing FUD on this....
Fighting for peace is like fucking for virginity
Well put. If a comparable NT exploit were available you can bet the Slashdot
editors and readers would have been quick to drag MS over the coals. But since
this is a Linux love-fest, we just get a pointer to the fix, and probably later
some rationalizations as to how this points to the Linux's superiority, or how
this is really minor anyways. Reminds me of arguments I used to foolishly
engage in with creationists; anything that supports their argument is treated
as scientific evidence, while anything contradictory is dismissed out of hand
or ignored completely.
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$
#
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.
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.
I need a TiVo for my car. Pause live traffic now.
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:
I'm seeing a lot of comments like "This is only a local root exploit", or michael's "Important for anyone running a multi-user system."
That's crap. This is a big deal. Don't try and downplay this. If you leave this unpatched, it turns every remote login hole into a remote root hole. There's plenty of code running remotely: mail, cgi, etc. Good security isn't foolproof. Good security is defense in depth. That means that you are patched against remote holes, and patched against local holes, so that escalation of privileges is difficult.
--sam
--sam
Any technology distinguishable from magic is insufficiently advanced.
It will hopefully make Linux users a little less complacent (and smug) than before.
In your dreams. As a Linux user, I'm smugger than ever. How can that be? Well, let's see: a huge bug is found in Linux kernel. Did anyone write an exploit that pur millions of Linux computers in jeopardy? No. Did a malicious worm get released and wreaked havoc on the Internet? Um, no. Did this bug cause ANY inconvenience AT ALL thus far? Um, no. And it never will. Why? Because 1) a patch was made instantly available, and 2) generally, Linux people have enough common sense to stay up to date with kernel patches. Sho why the hell shouldn't I be smug?
Mac OSX also got a remote root exploit of its own.
I don't know whether it's ironic or not that the introduction of open source software led to the first Mac-based remote exploit that I can remember in a long, long time. I'm leaning against it as code's still made by humans and humans still make mistakes. You'd be well-advised to remember this and temper your flames against Any OS That Isn't Mine next time.
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
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.
If you have stupid and malicious users, ulimit is your friend. And process accounting. And a baseball bat.
Szo
Red Leader Standing By!
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"
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.
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).
'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?
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
And a baseball bat.
Shh! Not so loud! My boss still thinks that a LART is a sophisticated piece of network analysis hardware. I never told him that the bills we get for replacing broken LARTs come from the Louisville Slugger Company.
That's "Mr. Soulless Automaton" to you, Bub.