Trouble with modutils. Thanks to the work of Sebastian Krahmer and Michal Zalewski, a severe security bug
has been found in the way the modutils package and the kernel interact. With help from a program like ping,
it is possible for a hostile user to obtain root privileges on the system - not good.
  
The problem is interesting to look at, since it shows how hard it can be to get things right.
  
The kernel can be configured to dynamically load modules when needed, and almost all distributions ship
kernels with that capability. To implement dynamic loading, the kernel provides a simple function:     

     int request_module(const char *module);
  
A kernel function which wants to load the driver for the eth0 Ethernet interface will thus call:

     request_module("eth0");
  
to cause that load to happen. request_module, in turn, eventually ends up creating a separate kernel thread
which runs the command:

     /sbin/modprobe -s -k eth0
  
(Where eth0 is whatever was actually passed to request_module). The modprobe utility is supposed to make
sure that the module gets loaded into the system.
  
The core of the problem is that whatever is passed to request_module ends up directly on the modprobe
command line, with no sanity checking. An additional problem that made things worse is that modprobe
implements filename expansion on the module argument by passing it to echo - meaning that the string passed
to request_module ends up being passed to a shell. Thus, if some crafty user can figure out a way to get
the kernel to call request_module with a specific string, there will be no end of opportunities for
mischief.
  
The ping command has an option -I, which tells it to use a specific network interface. ping will try to
configure that interface; if it doesn't exist, the kernel will try to set it up with, yes, request_module.
Thus the exploit for this problem is:

     ping -I ';chmod o+w .'
  
This exploit takes advantage of modprobe's filename expansion; the actual chmod command will be executed by
the shell as root, and will change the permissions on the root directory. A bit of cleverness from there
will allow an attacker to open up the system completely.
  
One could argue about whether modprobe should be performing the filename expansion. But the real problem is
that the kernel, by running modprobe in a privileged mode with unchecked data, is essentially giving
privilege to arbitrary user input.
  
Keith Owens released modutils-2.3.19, which fixes the exploit above and which is the basis of SuSE's
security update (see [17]this week's Security page). It works by turning off the filename expansion, but,
as it turns out, it's not a complete solution. Consider this variant:  ping -i '-C/my/config/file'
  
Here there is no reliance on filename expansion; instead, modprobe simply gets a new (hostile)
configuration file and anything can happen. So modutils 2.3.20 is on its way, and will likely be available
by the time you read this; it works by treating all kernel-supplied data as entirely untrustworthy - all it
can be is an exact name of a module found in the standard search path.
  
Even that doesn't fix the problem that the hostile user can cause the system to load any module that exists
in the search path. This could be a problem if a security bug turns up in a standard module, or if the
attacker is somehow able to insert a hostile module in modprobe's path. There is no easy way around this
one, other than to disable dynamic module loading.
  
It seems strange that modprobe should have to treat information that comes directly from the kernel as
potentially hostile. The sad truth is that validating user input is hard - especially when that input is a
character string which is to be passed to an external program. The kernel could perform some basic sanity
checks on that string, but the kernel does not really know how to interpret the string - that is what
modprobe is for. A complete solution to the problem is likely to be hard to come by.