kerneld auto-load of modules requested by unprivileged users

Date: Fri, 26 Sep 1997 23:18:12 -0400 (EDT)
From: Zygo Blaxell <zblaxell@fiction.org>
To: linux-security@redhat.com
Subject: [linux-security] kerneld and module security

Here's a neat trick for a machine running kerneld:

	not_root@machine$ /sbin/ifconfig isofs

loads '/lib/modules/(kernel version here)/fs/isofs.o'.

/sbin/ifconfig when run as non-root queries a network interface for
its configuration.  However, if the interface is unknown it also tries
to load the module that implements that interface using the name of the
interface as the token for kerneld (it's usually aliased to "3c59x.o"
or something appropriate to the installed hardware in /etc/modules.conf).
However, kerneld will happily load a filesystem driver or anything else
in the list of directories compiled into it as long as its name matches
the "interface-name" parameter.

Corollary:  Any module in /lib/modules can be loaded into kernel memory by
any user at any time.  There are potential denial-of-service attacks
from autoprobes and device initialization all kinds of other goo that
I wish I didn't have to think about here.

Here are four alternative fixes:

Fix 1:  Add a keyword to /etc/modules.conf that puts kerneld Into a
mode where nothing that wasn't explicitly listed in /etc/modules could
be loaded.  The defaults are nice and convenient, but too dangerous
when any user could ask for potentially dangerous modules by name.
This is probably the best solution of the four.  Vendors can generate an
/etc/modules.conf as part of system installation; most of the modules are
harmless, only device drivers with autoprobes are a significant threat,
so most of /etc/modules.conf will be constant.

Fix 2:  Make whatever system call that ifconfig executes to get interface
information fail if there is no such module installed and the request
is not made by root.  And close all similar problems, e.g. in mount's
filesystem parameter.  I don't actually advise this fix; we'd never
manage to get it right.

Fix 3:  Don't use kerneld.  Load modules manually or compile all modules
directly into the kernel and don't use insmod/modprobe/kerneld at all.
This is a short-term solution for people under attack.

Fix 4:  Never install a module you do not intend to use.  This sort
of defeats several of the benefits of modules, but not all of them.
If you were using modules to simplify configuration of many machines,
you'd have to explicitly choose which module files were installed on
each machine based on what is safe for that machine.

I've tried to do something like:

	/sbin/ifconfig ../../../../tmp/evil.o	# evil net interface ;-)

except that there are two problems:  first, it seems like modprobe won't
actually load a module that isn't listed in modules.dep; and second, the
interface chops it off at "../../../../" followed by four garbage characters.
I haven't checked the source code so I won't say it's impossible though.

-- 
Microsoft Magic Line, The: n; the curve on a price-performance chart defined by
the set of current shipping MS products.  New MS products shift the MML upward. 
Competitive products that fall below the MML become unmarketable and disappear. 
Hence, Microsoft is always the worst marketable solution for any real problem.

--
----------------------------------------------------------------------
Please refere to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------

To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null