Slashdot Mirror
Local Root Hole in Linux Kernels
xepsilon writes "A local Linux security hole using ptrace has been discovered that allows a potential attacker to gain root privileges. Linux 2.2.25 has been released to correct this security hole, along with a patch for 2.4.20-pre kernels. 2.4.21 ought to contain this fix, once it is released. 2.5 is not believed to be vulnerable to this security hole. See this email from Alan Cox for details, and a patch."
With all the brainpower on /. I'm sure we can discover a way.
Got Root?
Journal Entries:
(looks at watch) its monday again... time to go patch my IIS
(looks at watch) its tuesday again... time to go patch linux.
Got an e-mail this morning from Redhat Network that a new kernel was available to solve this vulnerability. up2date got my machine patched hours before the /. post.
If you're running Redhat, RHN is a valuable tool that no admin should be without.
There is no reasonable defense against an idiot with an agenda
:wq
Ptrace hole / Linux 2.2.25
To: linux-kernel@vger.kernel.org
Subject: Ptrace hole / Linux 2.2.25
From: Alan Cox
Date: Mon, 17 Mar 2003 11:04:35 -0500 (EST)
Sender: linux-kernel-owner@vger.kernel.org
-----------------------
Vulnerability: CAN-2003-0127
The Linux 2.2 and Linux 2.4 kernels have a flaw in ptrace. This hole allows
local users to obtain full privileges. Remote exploitation of this hole is
not possible. Linux 2.5 is not believed to be vulnerable.
Linux 2.2.25 has been released to correct Linux 2.2. It contains no other
changes. The bug fixes that would have been in 2.2.5pre1 will now appear in
2.2.26pre1. The patch will apply directly to most older 2.2 releases.
A patch for Linux 2.4.20/Linux 2.4.21pre is attached. The patch also
subtly changes the PR_SET_DUMPABLE prctl. We believe this is neccessary and
that it will not affect any software. The functionality change is specific
to unusual debugging situations.
We would like to thank Andrzej Szombierski who found the problem, and
wrote an initial patch. Seth Arnold cleaned up the 2.2 change. Arjan van
de Ven and Ben LaHaise identified additional problems with the original
fix.
Alan
And for the hax0rs without a local shell, there's a recent samba instant-remote-r00t vulnerability. Get your patches while they're hot!
(Server Room, DP) A hole was found in 'cypress', one of the principle Linux file, email and web servers of Brapco Corp early today. "We were dusting out around the back", said Mike Koyro, IT manager of Brapco, "and there it was, right by the power supply." The hole was quickly verified by other members of the IT dept as "really there". Speculation that it may be a screw hole was quickly dispelled when Frank, chief scripting officer, pointed out it didn't have any threads, and no screws were found loose anywhere nearby. "If someone got in here and drilled it during the night, they sure did a clean job - there's no shavings on the floor and the hole has no burrs" observed Mike. "It was either a professional job, with a sharp bit and machining oil, or a manufacturing defect". Calls to Linux Security were unanswered as of press time.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Haleulia and pass the green beer. It's not in Welsh.
BTW: If you haven't read, or tried to read, Alan's blog you won't get the joke.
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
Different mirror
I guess these are the same.. haven't read the origial ./ed site, but this is from lklm and guess they're the same...
This is already at least the second problem somehow connected with ptrace() in the kernel. Kernels prior to 2.2.19 were vulnerable to a race-condition attack, that enabled local users to gain root privilegies. This was one of the most "famous" problems in last years and it's known as the execve/ptrace exploit.
More details:
This vulnerability exploits a race condition in the 2.2.x Linux kernel within the execve() system call. By predicting the child-process sleep() within execve(), an attacker can use ptrace() or similar mechanisms to subvert control of the child process. If the child process is setuid, the attacker can cause the child process to execute arbitrary code at an elevated privilege. There are also other known lesser security issues with Linux kernels prior to 2.2.19 which have been noted as fixed.I don't know. Let's ask the U.S. Army what they think of Microsoft after the latest server hacking.
I do not have a signature
We're not patching, we're in denial.
____
ATS11=0 the secret to beating everyone else to a 1 line board.
I hate to say it, but this is kind of refreshing. This ins't a troll, so don't get me wrong...I'm a linux user myself. But after seeing the masses rip into MS yesterday when the thread about the IIS 5.0 hole was posted, I got a tad frustrated. Granted, I hate Microsoft as much as the next guy, but this just goes to show you that it's NOT just Microsoft that falls prey to holes and exploits. If it runs an OS, there's a chance it'll be cracked. Simple as that.
Hell, the linux kernel is without a doubt one of the most audited open source projects out there, and this bug STILL didn't surface until 2.4.20. Of course, I applaud the speed and availibility of patches and workarounds to the bug. Just remember, it happens to everyone.
"Hell hath no fury like a woman scorned for SEGA. ..."
Does that mean you have to be at the keyboard, or does that mean you have to have access to the box itself? (a shutdown/restart exploit?)
This means that you have to already have an existing user account on the system, running in user space. You cannot exploit the box without having (control of) a user account.
If you are at the keyboard, you can usually get root instantly on Linux. "lilo: linux single"
Dacels Jewelers can't be trusted.
Anyway, another copy of the patch.
- Sam
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
Have you considered the possibility of someone exploiting a non-root remote hole on your box and now having the ability to escalate themselves to root?
If you can't patch this right away, you can easily work around the hole. In order to be vulnerable, you need to have kmod enabled in the kernel, and /proc/sys/kernel/modprobe must contain the name of ANY VALID EXECUTABLE. It doesn't have to be /sbin/modprobe. Even /bin/false is vulnerable on this one.
/this/file/aint/there > /proc/sys/kernel/modprobe
To prevent the exploit, give the kernel a bogus filename to use as modprobe, like this:
cat
If you only use kmod to load modules at boot time, you might consider having this run after all your other init scripts, say in rc.local.
Pat
No, but a good bet is to reinstall MD5-verified binaries of netstat and ps, and then look for suspicious processes or network servers. All of the rootkits I've seen work by running a hidden background process, or by modifying the kernel -- and you're replacing the kernel, so that should be ok.
Until the patch has been tested and distributed, you can prevent the bug from being exploited by locking the door to your office.
Geez, only took /. 27-odd hours. Anyway.
...) a uid 0 modprobe (easy enough way to call kernel_thread()), but for some reason, the traced process isn't properly reparented, so all subsequent ptrace() calls fail. (Whenever you PTRACE_ATTACH to a process, it's supposed to become the child process of the tracer, and ptrace_check_attach (linux/kernel/ptrace.c) will return -ESRCH if this condition isn't met.)
I tried writing an exploit for this flaw, but I couldn't get far enough to inject any code. I managed to ptrace(PTRACE_ATTACH,
I'm not positive this is actually exploitable, but I'm not positive I took the correct approach, either. In any case, the most I've been able to do is spawn a slew of suspended root-owned processes. Not good, but not the end of the world, either. If someone has actually managed to exploit this flaw, I'd love to see some code so that I could see what I did wrong. Conversely, I'm willing to share the code I have upon request. I've only written code up to the current impasse, but once past this problem, the rest should be pretty trivial.
It fails on include/linux/sched.h with default patch options. Which kind of sucks. You can get it to 'work' by giving patch a fuzz-factor of 3, but then the build fails. Not a very usefull patch. /usr/src /otherhome/stor/src/linux/linux-2.4.20.tar.bz2 | tar xv
cd
mv linux-2.4.20 linux-2.4.20_OLD
bzcat
cd linux-2.4.20
patch -p1
fails at include/linux/sched.h
If you do 'patch -p1 -F 3' instead, it won't fail, but the fuzz factor obviously leads to a patch error, as the compilation breaks [as soon as include/linux/sched.h is included, BTW]
I mean, I appreciate knowing that my system is horribly vulnerable, but a WORKING FIX would sure be nice.
---
the pen is mightier than the sword, the sword is mightier than the court, the court is mightier than the pen.
I know "Cymru" means "Welsh" but that's about it.
:o)
Tux, the beloved Linux mascot is Welsh!
It's true! Tux is a penguin..
Penguin is derived from two Welsh words: Pen (head) and Gwynn (white)...
So (besides Alan) there is another link between Wales and Linux.
(That, and I've tripled your knowledge of the Welsh language
Everyone's taking comfort in the fact that no remote exploitation is possible, but remember all those universities that you've convinced over the past few years to switch from proprietary UNIX to Linux for their cs department and mail servers? The ones with thousands of local accounts given out to all the students and faculty? Yeah, they might not be happy about this.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I second that opinion. However, many sysadmins have a responsibility for public servers (lots of ports open even with a firewall). As such these same sysadmins are smart and have a redundant box to do things like patch a system.
In addition, some small businesses don't have the luxury of a secondary box or even an IT specialist that can put a machine through a high-load test for more than a few hours at a time -- let alone having to patch it at all!
Ideally we would all have a RAID 10 array connected to four boxes each running a different OS. While some companies (!) may have the time and money for this, the small folks like mom-and-pop stores can't afford the expense of time or money.
$DEITY bless $NATION
Of course, it is good that these kinds of bugs get fixed. Some people do run multiuser systems, and it provides an additional barrier against intrusions. But don't lose any sleep over it.
Incidentally, these kinds of exploits are probably rampant on Windows systems; there, people don't even bother looking for them because there are very few multiuser machines and most people have local Administrator privileges anyway. Also note that Microsoft didn't even try to get Windows certified secure for multiuser use.