Bug 20749 - local root exploit via modutils
local root exploit via modutils
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: modutils (Show other bugs)
7.0
All Linux
high Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
David Lawrence
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-13 05:19 EST by Daniel Roesen
Modified: 2007-03-26 23:37 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-11-17 18:39:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
exploit script (1.18 KB, text/plain)
2000-11-13 05:21 EST, Daniel Roesen
no flags Details

  None (edit)
Description Daniel Roesen 2000-11-13 05:19:27 EST
From: Michal Zalewski <lcamtuf@TPI.PL>
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: RedHat 7.0 (and SuSE): modutils + netkit = root compromise. (fwd)
Date: Sun, 12 Nov 2000 22:46:53 +0100

Motto from the modprobe manpage: "BUGS: Naah..."
------------------------------------------------

This vulnerability has been found by Sebastian Krahmer some time ago (he
is posting an advisory right now). Stupid shell command execution within
userspace kernel helper application, modprobe, is something you do not
want to see. But it happened. I have no idea how could it be introduced in
RH 7.0 systems and some other distros (like recent SuSE), but it was. Ugh.

Well, Sebastian believed this vulnerability is really difficult to exploit
(at least in standard configurations). I had the same feeling about it.
But, after being asked by Sebastian to do it, I've found some time and
decided to investigate it more carefully. First of all, I've tried to find
any way to exploit it in RH 6.2 environment with "upgraded" modprobe. No
success. Then, I've switched to brand new, shiny RH 7.0 installation. And
voila - nothing easier. Attached exploit is somewhat hackish - abusing new
ping utility in this system to exploit modprobe vulnerability. As slashes
in device name are rejected by modprobe and environment is not preserved,
this exploit works in really weird way, operating on modprobe's pwd (/),
making it world-writable for a second.

NOTE: if this exploit fails, it does not have to mean your modprobe is
secure; it might mean your system is equipped with, for example, old
/bin/ping utility, instead of new iputils software. You should be aware
that RedHat released some iputils updates, which apparently seems to
"accidentally" fix this particular way to exploit it. But this utility is
only an instrument used to exploit the bug. You can play with other setuid
programs, /bin/ping6, privledged services etc. Be creative.

Well, two applications were upgraded and shipped in the manner which opens
really huge root compromise possibility. Well done, RedHat :)

Greetings to Sebastian, of course, to Solar Designer, kil3r, Nises, Scott,
Dave, Simple Nomad, Aleph One, #hax and all the people :)

_______________________________________________________
Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=
Comment 1 Daniel Roesen 2000-11-13 05:21:33 EST
Created attachment 5300 [details]
exploit script
Comment 2 Jeremy Katz 2000-11-13 11:20:35 EST
This affects Red Hat Linux 6.x as well.  Patch from Keith Owens was posted to lkml and can also be found at http://lwn.net/daily/modutils-patch.php3
Comment 3 Chris Evans 2000-11-14 05:56:13 EST
Note that a secure solution might need to be in the kernel.
Why?
Consider this: request_module() is called with a module name starting with "-".
Now, when modprobe is executed, the module name will look like an argument!
This is very dangerous, especially with the "-C" modprobe option to specify an
alternate config file.
Comment 4 Daniel Roesen 2000-11-14 08:28:27 EST
Update:

Keith Owens [modutils maintainer] wrote on linux-kernel recently:

<--cite-->
I have nearly finished the security review of modutils, 2.3.20 will be
out later tonight.  It treats the kmod environment as tainted, forces
the last parameter to be treated as a module name even if it starts
with '-', only accepts one module name and refuses 'variable=value'
strings.  I find it rather ironic to be treating kernel supplied data
as tainted.
<--cite-->

And yes, Chris. The kernel needs auditing in this area, too.
Comment 5 Andrew Bartlett 2000-11-17 18:39:06 EST
The other way off looking at this is that the set-uid root programs are sending
untrusted user-supplied data to the kernel, which is already checking that this
data is from a root/set-uid-root source.

It should be set-uid utilities that are checking this data, dropping the extra
capabilities they don't need as well.  (I beleive that this is why ping isn't a
problem, it dropped all privilages bar CAP_NET_RAW before doing anyting).

If this bug is fixed at all the layers then there is less chance of this
happening again.
Comment 6 Daniel Roesen 2000-11-21 09:49:10 EST
closing, as ERRATA is out of the door.

Note You need to log in before you can comment on or make changes to this bug.