Local Root Hole in Linux Kernels 503
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."
Here's the text of Alans post (minus the .diff) (Score:4, Informative)
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
dead already? (Score:4, Informative)
In other news... (Score:5, Informative)
FYI, Red Hat Network Advisory (Score:3, Informative)
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.
Re:Could someone post the email up? (Score:5, Informative)
Different mirror [theaimsgroup.com]
I guess these are the same.. haven't read the origial ./ed site, but this is from lklm and guess they're the same...
Re:Kernel Patches (Score:3, Informative)
ptrace() again? (Score:5, Informative)
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.Re:Linux disclosure procedures? (Score:5, Informative)
Re:Could someone post the email up? (Score:2, Informative)
Re:Stupid question... (Score:5, Informative)
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"
Re:Stupid question... (Score:4, Informative)
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.
Simple workaround (Score:5, Informative)
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
Re:Root Kit (Score:5, Informative)
Re:Simple workaround (Score:3, Informative)
Oops... While the above also happens to work, what I meant was more like this:
echo "/this/file/aint/there" >
Pat
workaround without reboot by disabling ptrace() (Score:2, Informative)
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.
Patch won't apply to linux-2.4.20 (Score:5, Informative)
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.
Re:Don't forget us 2.0.x users. (Score:3, Informative)
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.
Re:patched it already (Score:3, Informative)
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.
Re:In Soviet Russia... (Score:3, Informative)
Re:Linux disclosure procedures? (Score:3, Informative)
You will deploy Linux patches on production machines without testing?
Re:How is Microsoft responsible? (Score:3, Informative)
Parent isn't troll. Patch really won't apply (Score:2, Informative)
Re:Root Kit (Score:3, Informative)
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.
Clean patch against 2.4.20 (Score:3, Informative)
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 [hardrock.org]
http://www.hardrock.org/kernel/2.4.20/linux-2.4.2
Sorry if you get /.ed.
Re:Mod Parent Down (Score:3, Informative)
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
Re:Parent isn't troll. Patch really won't apply (Score:1, Informative)
patch for 2.4.21-pre5 [indiana.edu]
Got these from a LKML archive [indiana.edu] that handles attachments nicely.
Patch for 2.4.20 from LKML (Score:4, Informative)
Re:Linux auditing (Score:1, Informative)
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
Re:Exploitable? (Score:4, Informative)
An anonymous writer at kerneltrap.org [kerneltrap.org] provided this link for a working exploit:
http://isec.pl/cliph/isec-ptrace-kmod-exploit.c [isec.pl]