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."
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!
Red Hat Security Advisory
- up grade/
Synopsis: Updated 2.4 kernel fixes vulnerability
Advisory ID: RHSA-2003:098-00
Issue date: 2003-03-17
Updated on: 2003-03-17
Product: Red Hat Linux
Keywords: ptrace
Cross references:
Obsoletes: RHSA-2003:025-20 RHBA-2003:069-12
CVE Names: CAN-2003-0127
1. Topic:
Updated kernel packages for Red Hat Linux 7.1, 7.2, 7.3, and 8.0 are now
available. These packages fix a ptrace-related vulnerability that can
lead to elevated (root) privileges.
2. Relevant releases/architectures:
Red Hat Linux 7.1 - athlon, i386, i586, i686
Red Hat Linux 7.2 - athlon, i386, i586, i686
Red Hat Linux 7.3 - athlon, i386, i586, i686
Red Hat Linux 8.0 - athlon, i386, i586, i686
3. Problem description:
The Linux kernel handles the basic functions of the operating system.
A vulnerability has been found in version 2.4.18 of the kernel. This
vulnerability makes it possible for local users to gain elevated (root)
privileges without authorization. This advisory deals with updates to
Red Hat Linux 7.1, 7.2, 7.3, and 8.0.
All users of Red Hat Linux 7.1, 7.2, 7.3, and 8.0 should upgrade to
these errata packages, which contain patches to fix the vulnerability.
4. Solution:
Before applying this update, make sure all previously released errata
relevant to your system have been applied, especially the additional
packages from RHSA-2002:205 and RHSA-2002:206.
The procedure for upgrading the kernel manually is documented at:
http://www.redhat.com/support/docs/howto/kernel
Please read the directions for your architecture carefully before
proceeding with the kernel upgrade.
Please note that this update is also available via Red Hat Network. Many
people find this to be an easier way to apply updates. To use Red Hat
Network, launch the Red Hat Update Agent with the following command:
up2date
This will start an interactive process that will result in the appropriate
RPMs being upgraded on your system. Note that you need to select the kernel
explicitly on default configurations of up2date.
Karma: The shiznight, mostly because I am the Drizzle.
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...
When does it take a week? The WebDav exploit? That's because blackhats found it... They usually don't disclose.
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
-'fester
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.
A remote exploitation means that if your are connected to the internet, (And, in the case of a server deamon, running the affected daemon), then a remote attacker (== only using net acesses) can obtain root privs.
A local exploit menas that the attacker must be first logged in as a local user (i.e. have a valid account, or have exploited a server daemon to obtain local, unprivildiged access).
Attacks that require you to have physical acess to the box are generally not classified, as these will always exist (through boot disks, etc), and as thus not audited for.
It is a common practice to use an insecure deamon to first get local acess, then to use a local root hole, such as this one.
Hope that helps - the jargon is dense, but useful.
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.
After the last ptrace() fiasco, there was a temporary workarounds in the form of loadable modules which stub out or wrap the ptrace function. For servers where downtime and reboots must always be scheduled in advance, such a fix was well received.
You can create such your own module containing a do-nothing fake_ptrace function. In init_module(), set sys_call_table[__NR_ptrace]=fake_ptrace so the fake ptrace gets run instead of the real one. Search google for "no ptrace module" to find a few readymade ptrace wrapper/stub modules.
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.
What makes 2.0.x better for you than a 2.2 or 2.4 kernel?
Depends on the box. A better question is "what makes 2.2 or 2.4 better for me than 2.0?"
I have a few 2.0.x boxes kicking around that "just work".. they've never been down, there are no known exploits for them, and users would be pissed if I took them down to upgrade them.. so it just makes sense to leave them as is.
If I upgrade them, it's more work, not to mention the inevitable downtime.
If I leave them be, it's less work, with no gain (there's nothing that 2.2 or 2.4 will do that I need for these boxes.)
Pretty simple decision.
If/when they break, I'll replace them with something newer.. but until then, I'll just leave them be.
There is one difference: who do you trust?
I trust Redhat not to slip spyware and weird license agreements into the kernel I'm downloading. I trust that it's an honest to God GPL'd kernel. Why? Because I'm a trusting person, and I haven't had any freakish incidents with Redhat.
I don't trust Microsoft. I don't want code with God knows what hacked in with a license agreement that takes away my first born while installing.
While I'm on the subject, I received an e-mail from Microsoft before I recieved the e-mail from RHN. I then had the option of doing a Windows Update or installing it manually. I chose manual, because MS doesn't know about my machine and I want to keep it that way.
There is no reasonable defense against an idiot with an agenda
:wq
I'm new to Linux, so I might be wrong, but: If the minor version 2.x is odd, its a development/beta/alpha/whatever kernel. So 2.3 became 2.4, and no one should be using 2.3 on a production box. 2.5 is the current development branch, and when it is final it will be renumbered to 2.6. At that point no one should be running 2.5 on any box that matters.
Vote for global prefs bug
You will deploy Linux patches on production machines without testing?
MSDOS: 20+ years without remote hole in the default install
Voltaire wasn't an actor. He's one of the more important French philosophers of the 18th century. He basically developed a philosophy of logic, that bans poverty. But he would certainly be most annoyed about flaws in anything, but especially the Linux Kernel, since he was a promoter of free and open work, and flawlessness.
to linux-2.4.20
---
the pen is mightier than the sword, the sword is mightier than the court, the court is mightier than the pen.
Doesn't help much though if the user has developed something of their own that flies below the radar. Chkrootkit doesn't hurt for a bit of peace of mind.
This is probably way too late in the discussion to get seen, but Alan's patch won't apply cleanly to 2.4.20.
A clean patch can be found here:
0 -ptrace.patch
http://www.hardrock.org/kernel/2.4.20/linux-2.4.2
Sorry if you get /.ed.
Um, no, I'm afraid the guy (Rain) _does_ know what he's talking about (since I know him), and I've done a fair amount of kernel hacking in my day.
3 03 .2/0271.html
If you'd actually like to read something on-topic, see Ben Pfaff's response to Alan's post. The short of it, "we're [i.e. you're free to do it!] working on a correct fix for all cases, this is just the quick sledgehammer."
http://www.uwsg.iu.edu/hypermail/linux/kernel/0
Further in the thread, there is a patch against 2.4.20.
To: BugTraq
Subject: Locally exploitable races in OpenBSD VFS
Date: Jun 2 2001 7:00PM
Author: Alexander Viro
Message-ID:
Frankly. my respect to Theo went way down. This code had never been read
through, let alone audited. And that's the core kernel. Moreover, the
same bugs had been fixed in FreeBSD half a year ago. In other words, just
keeping an eye on other *BSD trees would be enough to catch them. Same
for lurking on freebsd-hackers. Same for watching the Linux tree, where
an audit of relevant areas had been done nearly two years ago. Done and
discussed on linux-kernel. Sad...
http://www.securityfocus.com/archive/1/188474
An anonymous writer at kerneltrap.org provided this link for a working exploit:
http://isec.pl/cliph/isec-ptrace-kmod-exploit.c