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!
I always hear people saying how great open source software is, because they can look through the code and fix any bugs themselves.
But I've always wondered exactly who's looking through all this code? Apparently not enough people if a bug this big has lasted this long.
I used to bulls-eye womp-rats in my pants
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!!!
Well, I only "Admin" of a very small network and when I started out with Linux (nearly 2 years ago) I thought: updating a kernel?!? Oh, no! I'm sure I'll never be able to do that! :-)
Ehm, well, some nice evening, when I had a lot of spare time, I downloaded the latest kernel and only read the README (or was it INSTALL???) and compiled/installed and was running my own custom compiled kernel.
No, an Admin worthy of the name should at least be able to read the (provided) docs and type at the command line. The Linux-kernel people really made it easy to compile your kernel IMNSHO. Honestly, even an NT-Admin must be able to read the docs otherwhise he woudn't know that, for example, after Windows asks it's original CD you have to re-apply your service-packs.
I admit, between Linux and Windows the environment changes, but the ability to read the instructions is needed everywhere as an Admin (and dare I say, as a normal user too!)
Besides, any sane admin has a production and testing environment....so compiling the kernel on prod machines should only be done after extensive testing.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
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)
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.
As long as we're going for broke, how's about a little preemption too?
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.
I find the tone of this post to be part of a disturbing, if subtle, trend.
I know this isn't new ground to tread in these forums, but the respective tones of posts about Microsoft bugs and Linux bugs are worthy of change.
When there's an MS bug, the posts generally read something like... "User writes, "Here's a big surprise. There's a bug in IIS that lets any six year old root the box. Excuse me while I gasp in surprise. Exploits are here and here. Cnet has the whole story." It's amazing that people still rely on IIS... I wonder when people will stop making their software choices entirely based on FUD."
When there's a bug that eluded many major kernel revisions, the post reads: 'Apparently there's been a bug in the kernel for months that yields unauthorized remote access to root. Huh. Users of multi-user systems might want to patch this when they get a chance.' -- and it's on to the next story.
Disparities such as these, subtle as they are, affect Linux communities' credibility. It makes us look immature because we appear to apply a double standard. It's a chink in our armor we should patch ASAP.
Mod parent down:
There is absolutely NO REASON for you to have passwd suid-root. NONE. All that would allow you to do is set root's password from a normal user's account. Or, for that matter, anyone's password.
Ping??? Ummmm.... NO. It can send and recieve packets fine and dandy as an unpriveleged user. Unless you want to ping-flood, which it will only let root do.
XTERM???? Goodnight, that's most insecure thing I've ever heard! When an xterm starts, it opens up a shell for whatever user it's running as. Even if that means opening up a root shell.
rlogin was made to be suid-root.
su was made to be suid-root.
Top has no need for suid-root.
Traceroute is kind of nice to have as suid-root, but I'd rather just su to root than open it up.
Security is your friend. Especially when you have work on your computer. Because as soon as you get hacked (even by a script kiddie), it's pretty standard to mess stuff up.
$ uname -a ./ptrace-exp ./insert_shellcode 24982
Linux limbo 2.4.0 #8 sat jul 21 14:24:48 CEST 2001 i686 unknown
$ id
uid=1001(johan) gid=1001(johan) groups=1001(johan)
$ gcc insert_shellcode.c -o insert_shellcode
$ gcc ptrace-exp.c -o ptrace-exp
$
attached
exec
$ id
uid=1001(johan) gid=1001(johan) groups=1001(johan)
So what's up?
I've already mailed this person about it and showed them that 2.4.12 with grsecurity is NOT vulnerable. he should have pasted the id output after the "exploit" which shows it did not work. In addition, the exploit that he was using was the old one for 2.2. I've tested the new ptrace exploit on a 2.4.12 and grsecurity machine and it did not work either. Here's the output: ./ptrace
./insert_shellcode 5158
/lib/i686/libc.so.6
/lib/i686/libc.so.6
[spender@new spender]$
attached
exec
07740: find library=libc.so.6; searching
07740: search cache=/etc/ld.so.cache
07740: trying file=/lib/i686/libc.so.6
07740:
07740:
07740: calling init:
07740:
07740:
07740: initialize program: grep
07740:
07740:
07740: transferring control: grep
07740:
07740:
07740: calling fini:
07740:
[spender@new spender]$ id
uid=502(spender) gid=502(spender) groups=502(spender)
Slashdot should remove the false information from the site...
-Brad