Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is still 2.4.0-test10. Work continues on 2.4.0-test11, with the current prepatch being 2.4.0-test11-pre5. Test11 consists mostly of driver fixes (including, finally, the big IrDA update); there is also a fix for an obscure wait queue bug that could cause wakeups to be missed in certain situations.
Note that -test5 includes a change to /proc/cpuinfo which breaks VMWare and perhaps some other programs as well.
Ted Ts'o posted an updated 2.4 TODO list on November 12.
The current stable kernel release is still 2.2.17. The current 2.2.18 prepatch is 2.2.18pre21; it's getting closer to release but a couple of outstanding issues are still in need of resolution.
Randy Dunlap steps down as USB maintainer. Randy Dunlap announced that his job (at Intel) is taking him away from USB work, with the result that he needs to transfer the USB maintainer role to somebody else. Randy is the first person to have served in that role - previously USB changes had gone straight to Linus, which wasn't scaling well. Under Randy's leadership the USB project has grown and thrived, to the point that Linux now has a highly functional USB subsystem. Congratulations are due to him (and to the USB team as a whole) for a great job.
Randy's replacement will be Johannes Erdfelt, currently employed at VA Linux Systems.
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 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.
Code from IBM. The source for OpenAFS is now available. OpenAFS is the version of the Andrew File System which IBM is releasing under its "IPL" license. (Thanks to David Magda).
IBM has also released the first "reference implementation" of its Enterprise Volume Management System. EVMS is a logical volume manager, like LVM (which is already in the kernel). Unlike OpenAFS, EVMS is released under the GPL.
Other patches and updates released this week include:
Section Editor: Jonathan Corbet
November 16, 2000