[21559] in bugtraq
Re: insmod/modprobe behaviour in regards to non-root-owned modules
daemon@ATHENA.MIT.EDU (Keith Owens)
Tue Jul 17 11:00:55 2001
From: Keith Owens <kaos@ocs.com.au>
To: Toby Corkindale <tjcorkin@sa.pracom.com.au>
Cc: bugtraq@securityfocus.com
In-reply-to: Your message of "Tue, 17 Jul 2001 15:18:31 +0930."
<Pine.LNX.4.33.0107171456110.26570-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 17 Jul 2001 16:15:52 +1000
Message-ID: <3934.995350552@kao2.melbourne.sgi.com>
On Tue, 17 Jul 2001 15:18:31 +0930 (CST),
Toby Corkindale <tjcorkin@sa.pracom.com.au> wrote:
>According to the manual page for insmod, insmod should refuse
>to install a non-root-owned module, since otherwise exploits relating to
>compromised user accounts who own modules, or else a compromised
>modules.dep, are available.
>
>I would assume modprobe should follow this behaviour.
>However, see the below transcript for an example of modprobe differing.
>
>The insmod correctly denies to load the module, but modprobe happily
>installs it! (Note that modprobe is actually just a symlink to insmod,
>which checks the argv[0] to determine mode to run)
It loads because modprobe is trusting the data in modules.dep. You can
only get into this situation by one of two actions:
(1) root ran depmod with -r to allow modules not owned by root
(2) the module was originally owned by root but root changed the
owner or installed a new version, in either case they have not
run depmod after the change.
modules.dep is a trusted file. root builds it by hand or via a startup
script. If root changes the modules without refreshing modules.dep
then you have GIGO.
AFAICT you need root to do this, to update files and/or permissions in
/lib/modules. If you can reproduce the problem without requiring root
privileges at some stage and without using depmod -r then it is a bug.
Otherwise "root can destroy a system", this is not news.
