[21567] in bugtraq
Re: insmod/modprobe behaviour in regards to non-root-owned modules
daemon@ATHENA.MIT.EDU (Toby Corkindale)
Tue Jul 17 12:09:48 2001
Date: Tue, 17 Jul 2001 16:05:56 +0930 (CST)
From: Toby Corkindale <tjcorkin@sa.pracom.com.au>
To: Keith Owens <kaos@ocs.com.au>
Cc: <bugtraq@securityfocus.com>
In-Reply-To: <3934.995350552@kao2.melbourne.sgi.com>
Message-ID: <Pine.LNX.4.33.0107171558290.26570-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
josh@pulltheplug.com posted to bugtraq earlier today with a case whereby
modules.dep is set to mode 0666, and thus can be manipulated by a non-root
user to cause a common module to load a user-owned evil module.
According to his post, Linux kernels from 2.4.3 onwards have a default empty
umask, and thus on some distributions that do not explicity set the umask
in time, a world-writeable modules.dep is created on bootup.
This can be seen as a configuration error, perhaps, but I question whether
modprobe should bypass the root-ownership test, which seems like a good
idea.
I guess there are cases where being able to specify an
intentionally-non-root-owned module would be useful, but is that enough of a
reason to bypass the security check?
-Toby
On Tue, 17 Jul 2001, Keith Owens wrote:
> 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.
