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 (jackat_private), 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 (bj0rnat_private), 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 bks10at_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:41:14 PDT