insmod.linux.txt

1999-08-17T00:00:00
ID PACKETSTORM:12021
Type packetstorm
Reporter Packet Storm
Modified 1999-08-17T00:00:00

Description

                                        
                                            `Date: Tue, 30 Mar 1999 22:08:13 -0500  
From: Brian Szymanski <bks10@CORNELL.EDU>  
To: BUGTRAQ@netspace.org  
Subject: linux insmod bug/security vulnerability  
  
Howdy all,  
  
Recently I discovered a bug in insmod that would require a lot of time  
and luck to exploit, but is nonetheless important for systems wanting  
rock-solid security (security shouldn't be a matter of luck). In short,  
when insmod is called without a full path to the module to load, it  
checks a small path to find the module in question. By default, this  
path is the current directory followed by the /lib/modules/ heirarchy.  
In the widely distributed versions of the software, the module is not  
checked for root ownership, and there is no way to tell which file has  
been loaded after insmod is called. Needless to say, putting a malicious  
user's code in to the kernel and then running it in kernel mode is a  
very Bad Thing.  
  
LINUX DEVELOPERS, HOWTO-WRITERS, ETC... TAKE HEED!!!  
The listed maintainer of the program, Jacques Gelinas  
(jack@solucorp.qc.ca), informs me that modprobe (not insmod) should be  
used to load pathless modules from the /lib/modules heirarchy, but in  
practice most people (and precanned scripts) use insmod, compounding the  
problem. It appears that the well distributed versions of modprobe are  
NOT vulnerable to these bugs (tested on debian 2.1). ***Please change  
any documentation you write or scripts you distribute to use modprobe  
instead of insmod ASAP*** This should probably be forwarded to some sort  
of linux development list, but I know of none at the moment.  
  
VERSIONS AFFECTED, IMPROVED (if not fixed) VERSION:  
The versions included in debian, redhat, and most if not all other  
distributions are vulnerable as well. Any version previous to 2.2.2-pre6  
(available from  
http://www.pi.se/blox/modutils/modutils-2.2.2-pre6.tar.gz). Please  
upgrade to this version, which one of the package maintainers, Bjorn  
Ekwall (bj0rn@blox.se), informs me fixes the following issues:  
  
o A module has to be owned by root.  
  
o All "path-less" modules are resolved according to the list of  
paths in conf.modules (explicitly or via the built-in defaults).  
Note that all module utilities use the same configuration  
and thus the same paths in the new release.  
  
o If insmod is called without a path to the module, insmod will  
print the full path of the module it actually selects to install.  
  
PROBLEMS IN THE NEW VERSION:  
The new version is a big improvement, but not perfect (after all, it's a  
pre-stable version...) The last 2 points appear to be implemented fine,  
but the first is imperfect. The root ownership checks only appear to  
happen when the path to the module is not specified. I don't see any  
reason why you would ever need to load a module owned by a user, when  
you can just su and copy /chown it. Also, there is some oddness when a  
module in /lib/modules isn't owned by root. insmod spits out 24(!) lines  
like this:  
insmod: /lib/modules/2.2.4/misc/vmmon is not owned by root  
That's better, but I still don't like the idea of bugs in this area of  
the code...  
  
Another thing to be wary of: There may be some unresolved issues with  
groups and permissions, but it'd probably just be bloat for this package  
to worry about warning of those issues (IE, mode a+w modules or g+w  
with group != root). Then again, linux's swapon checks for the proper  
permissions on a swapfile/device, so perhaps it wouldn't be unreasonable  
to warn about permissions.  
  
I don't see what's so hard about just checking for ownership and  
permissions issues *after* resolving the full path of the module, but  
then again, I've been too lazy to RTFS so far, so sue me if it isn't  
that trivial.  
  
EXPLOIT:  
As previously mentioned, an exploit would require a lot of luck and  
time, but would basically consist of regularly throwing a lot of  
trojan'd .o files in /tmp, and waiting until root decides to clean out  
tmp right before loading some module... Far-fetched but too possible for  
comfort. Other scenarios along these lines could be imagined. Equally  
far fetched, but the point is the currently distributed versions don't  
do it the Right Way... It's a lot more likely that you would make your  
system crash and burn due to this bug (although files do seem to be  
checked to be in elf format before being loaded).  
  
Thanks for reading. Comments and constructive criticisms more than  
welcome:  
  
Brian Szymanski  
bks10@cornell.edu  
  
`