From: "Adam J. Richter" <adam@freya.yggdrasil.com>
To: kaos@ocs.com.au
Cc: linux-kernel@vger.kernel.org, vendor-sec@lst.de
Subject: Re: Local root exploit with kmod and modutils > 2.1.121
Date: Tue, 14 Nov 2000 12:31:41 -0800 [thread overview]
Message-ID: <200011142031.MAA07179@freya.yggdrasil.com> (raw)
>The only secure fix I can see is to add SAFEMODE=1 to modprobe's
>environment and change exec_modprobe.
SAFEMODE may mean other things to other programs, so that
an ordinary user might set that environment variable for some
other reason, and then get weird behavior if he or she has occasion
to su to root. In general, you only want to use environment variables
if either it is a user interface issue to keep the commands short
(not an issue here, since nobody is typing in the command that
requrest_module generates) or there is some well established
convention that will handled in a particular way by subordinate
child processes (e.g., PATH=....).
It would be much better to just add a command line option
to modprobe that request_module() would cause it treat the following
argument as the module to load (you do not ever have to force
argument processing to stop at that point, since module will be
fully contained in the next argument, even if it contains space or
linefeed).
Another possible approach would be to create a separate
/sbin/safe_modprobe. modprobe already behaves differently
based on whether argv[0] ends in "modprobe", "insmod", "depmod",
or "rmmod". So this would be in keeping with that convention.
It would also be trivial to retrofit old systems. Just have
some system boot script do:
echo /sbin/safe_modprobe > /proc/sys/kernel/modprobe
The issue of the kernel doing request_module() on arbitrary
strings is not just a security problem. It is also a namespace
collision problem, which this security concern will give us the
opportunity to fix. I have just been glad that no company has
shipped a networking device called, say, "ext2". The non-constant
module names that are loaded by request_module should have names like:
fs-msdos
fs-ext2
netif-eth0
netif-wvlan0
etc.
That way, a malicious user cannot cause a denial of service
by identifying one module with a loading bug (our kernels have 774 modules)
and doing, "ifconfig <modulename>".
The extra work of doing the snprintf() into a buffer
before invoking request_module will resolve the buffer overrun
issues too.
I would be happy to assist in coding this up. The 50 lines of
text that I have written in this email probably only translate into
20 lines of code.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next reply other threads:[~2000-11-14 21:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-14 20:31 Adam J. Richter [this message]
2000-11-14 22:50 ` Keith Owens
[not found] <Pine.LNX.4.21.0011131915240.19775-100000@ferret.lmh.ox.ac.uk>
2000-11-13 23:11 ` Keith Owens
2000-11-16 16:04 ` Alan Cox
2000-11-16 17:05 ` kuznet
2000-11-16 17:19 ` Alan Cox
2000-11-16 17:32 ` kuznet
2000-11-16 18:24 ` Alan Cox
2000-11-16 18:56 ` kuznet
2000-11-16 20:24 ` Keith Owens
2000-11-16 21:45 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2000-11-13 10:57 Keith Owens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200011142031.MAA07179@freya.yggdrasil.com \
--to=adam@freya.yggdrasil.com \
--cc=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=vendor-sec@lst.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®