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.
It's been /.ed and I'd really like/need to read it asap. Hence I am posting at +2. Karma burning away...
New marketing ploy for TMF: get your security news before the 13-year-old 5
Not so fast! What if they steal some CC numbers first?
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!
Lo-Cal Root Hole in Linux Kernels
I think I saw this in an advertisement for granola.
mmmm... breakfasty
Best Windows Freeware
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.
(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";
Soooo, i wonder how many posts will appear here along the lines of those in the WebDav exploit story earlier. Not many im willing to bet.
Those people willing to shout and hollor at every serious issue, screaming bloody murder because someone got it wrong, really pisses me off. Yes people get it wrong, they write insecure code from time to time. This issue and a number of those before it show that Linux has as many opportunities for exploitation as any other OS.
I guess they were just trying to out-do the IIS hole.
... there's always "linux single" ... :)
Ah well
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.1) umm, I got a mail from redhat about this same as I get something from MS.
2) I think you worry about crackers knowing not hackers, hackers fix problems like this. Also as anyone in a production environment knows just because MS does not publish it does not mean that people dont know before they have a fix. Also the time to deploy a MS patch in production is much longer due to shutdowns and testing.
3) As opposed to almost *ALL* MS updates which requres a restart of every server in your company Woo Hoo!
4) ??? 5) Profit
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
However, quoting some guy further down the page:
A Windows vulnerability is discovered and it takes a week or more to get it taken care of.
The Linux kernel has a vulnerability and the patch is available immediately.
We're not patching, we're in denial.
____
ATS11=0 the secret to beating everyone else to a 1 line board.
But at least they admit it when there are problems. As does the BSD crowd too.
And *nix is still a hell of a lot closer to perfect..
---- Booth was a patriot ----
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. ..."
Who's a sysadmin to trust?
Ummmmm, Ghostbusters?
KFG
I hate when I choose to reply instead of mod, but this needs to be said - they aren't the same!
I am not going to patch my Linux systems. Why? Because it isn't possible to exploit this vulnerability remotely. The only local user on my machine knows the root password (me). So it isn't quite the same severity as a bug in a widely distributed webserver. Yes, they are both serious, but compare apples to apples. (not that your comments aren't correct, just that you need to make them at the right time.)
My beliefs do not require that you agree with them.
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.
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.
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.
It isn't a remote exploit. Anyone who is foolish enough to attempt to h4X0r your b0X0rz with this vulnerability is within the normal attack range of a LART.
Please, do patch any affected machines you have as soon as possible, but don't *ahem* panic.
Soko
"Depression is merely anger without enthusiasm." - Anonymous
Until the patch has been tested and distributed, you can prevent the bug from being exploited by locking the door to your office.
With so very many vulnerabilities (and ever expanding), it's easy to see why you'd assume that Windows was the only buggy vulnerable bloated operating system. This isn't true. It just seems that way. It feels that way. And, considering how wide rangingly destructive Windows vulnerabilities tend to be, for all intensive purposes, it is that way. But, deep down, we all acknowledge that it isn't technically true.
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.
St. Patrick's Day, a perfectly valid and socially acceptable excuse to get rip-roaring pissed, and you say it's *only* for the Irish? I'm sorry, please hand in your geek membership card. You aren't allowed to post here anymore.
SQUEAK, the Death of Rats explained.
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.
Linux has security problems? I've been reading this site for so long, I thought that was only in Microsoft's domain.
We do want to make Windows users feel at home as they migrate to a Linux desktop. We don't expect 'em to go cold turkey right away.
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.
Where the hell are the debian people with a patched kernel? The patch alan cox provided doesn't apply cleanly to the debina modified kernel, so I am trying to hack it up now. But shouldn't someone in charge of security patches at debian have done this and had an update out?
COME ON WAKE UP!
Its bugs from code Billy-boy wrote under a pseudonym
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.
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
I think our friend Al Viro would have something to say about the auditing level of the Linux kernel. And if we're talking about drivers/ in particular, it would probably involve the words "obfuscated", "brain dead", "steaming pile of shit", "warped beyond all belief" ... :)
Linux code gets a fair amount of review. But once it's there, there really isn't any auditing at all.
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
At least in Debian, even with "linux single" you have to type the root password to get root.
How about with "linux init=/bin/sh"?
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
Never forget that proprietary, commercial UNIX solutions are also vulnerable to kernel-level bugs and exploits. I used to work for a university that deployed Linux and Solaris solutions - the patch sets for Solaris (kernel and userland utilities) were just as necessary as the Linux server installations.
The beauty of the Linux and open-source worlds is that the code is available right before your very eyes and is subject to scrutiny, day-in and day-out. Commercial offerings are not available to the general public, potentially leaving behind bugs that wouldn't be caught by the few who _could_ see the code. Code that is viewed by literally thousands of all programming backgrounds, versus code that is viewed by a select few which only specialize in that code, is more likely to be exploit-free.
This particular Linux kernel exploit was encountered by developers that recognized the flaw. And, luckily for us, the developers were talented enough (or knew someone in the core development group) that could quickly produce a patch so that administrators could secure their servers from being taken advantage from.
If the exploit was encountered in the commercial arena, the person who found the flaw would have to contact the company who supports the operating system. An assessment team would have to see the cause/effect/consequences of the exploit. Then, the development group would have to produce a patch. The company would then contact their support group to contact their enterprise customers first (more than likely) to deploy the patch. Finally, with the company's core customer interests intact, the company would publish their findings and solution for the remainder of the world. Many Microsoft patches are first released to their core enterprise companies - and then released via Windows Update (or through their web site).
For universities that have made the switch, there should be more peace of mind knowing that the quantity of security breaches on the kernel level are much less than the overwhelming number of Windows flaws (which generally require a reboot) and at a much cheaper price than a commercial UNIX offering.
Ayup
Yeah, that William H. Torvalds III has done a lot of damage with his weasly little kernel hacks, dammit.
Of course I will test, but the testing almost always takes less time because it does not break other services. When we had to patch windows to avoid all the SQL server crap a while back it broke the damn server, so in testing there is going to be more tweaking involved than one might have with a typical Linux patch..
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.
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.
While its not really kosher to bash an OS because of a single flaw, there is a fundamental difference in the case of this flaw and the previously announced IIS exploit: this one's not yet exploited. One thing that hurts FS/OSS on bug lists is that all *potential* exploits in open code will be listed as bugs, while many proprietary producst only disclose known, possibly exploited, bugs. Case in point, the IIS problem was exploited almost a week ago. The kernel problem was noticed, fixed, and no exploit exists. In fact, a previous poster on this board has posted his inability to trigger the *potential* exploit and asked for help.
I always get the shakes before a drop.
OpenBSD isnt vulnerable :P
When setting up security, I always assume any local user can get root priviledges and make sure I don't care that much. It makes life much easier and less worrisome.
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
NOW linux is ready for the desktop
Manipulate the moderator system! Mod someone as "overrated" today.
Further in the thread, there is a patch against 2.4.20.