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