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.
On Sun, 28 Sep 1997, Aleph One wrote: (forwarded from linux-security@redhat.com) <snip>> 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.see Brian Mitchell''s "hacked_setuid" module, that was released in phrack 50, article 5 (along with his linspy terminal snooper program).. what this module does is redirect the setuid() call so you can become superuser using a magic number. just think, if you could load this module at will without being root, all you''d need to do is whip up some code that does setuid(magic_number) and spawns a shell!> Here are four alternative fixes:#5 make /usr/lib/modules root read/write only TheFloyd
Pawel S. Veselov
1997-Sep-29 17:54 UTC
Re: [linux-security] Re: kerneld and module security
Hello, Patrick! On Mon, 29 Sep 1997, Patrick Cantwell wrote:><snip> > >> 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.>see Brian Mitchell''s "hacked_setuid" module, that was released in phrack >50, article 5 (along with his linspy terminal snooper program).. >what this module does is redirect the setuid() call so you can become >superuser using a magic number. >just think, if you could load this module at will without being root, all >you''d need to do is whip up some code that does setuid(magic_number) and >spawns a shell! > >> Here are four alternative fixes: > >#5 make /usr/lib/modules root read/write only[mod: Patrick was thinking about a user installing a special module, indeed the rest was thinking about what could be achieved without having to install a special module: denial of service. -- REW] Nah, this will not do the trick. kerneld is runned under root, so it will be able to insmod/rmmod modules. kerneld will take any modules from /lib/modules/.... only, so there is no problem that user can install he''s own module. Problem is DoS - some modules could cause problems for a systems with autoprobing hardware frequently or autoprobe collision with some other module. I really don''t believe, that somebody allows users to write /lib/modules/xxx... It is nice, I could compile some filesystems code as modules and let user load it. kerneld will remove module only after some timeout, so kernel will not go crazy for frequent insmoding/rmmoding. Bye. -- I know you think you thought you knew what you thought I said, but I''m not sure you understood what you thought I meant. -- With best of best regards, Pawel S. Veselov (aka Black Angel) internet : vps@unicorn.niimm.spb.su ( mail,finger,talk ) fidonet : 2:5030/5.412 schoolnet : 21:9000/412 Web page : http://www.niimm.spb.su/~vps/
Quoted from Chris Gorman:> If the keyword exists currently or needs to be implemented? > If it exists currently what is it?A number of people have asked me this, so I''ll cc back to linux-security. As far as I know there is no such keyword; it would have to be implemented and added to the modules.conf _syntax_. (I didn''t think I was that unclear; if I knew of such a keyword I would probably have mentioned it by name, eh? ;-) Someone with more time than I have will have to implement fix #1 (smarter modprobe). I''d recommend implementing something like a "permit" keyword, which would be followed by a space-separated list of permitted module names. Multiple ''permit'' keywords should be cumulative; there are lots of harmless modules and some of them are critical too. This would be interpreted by modprobe when kerneld calls it to load the module. modprobe''s algorithm would be: if at least one ''permit'' keyword is present in /etc/modules.conf, only attempt to load a module if it is listed on a ''permit'' line. After reading the sources a bit I noticed that you can also alias all of the modules that will cause problems when loaded to ''off''; however this means you need to keep a black list of bad modules instead of a white list of good ones. Yet another way to implement this would be to go after ''depmod'' and restrict what ends up in /lib/modules/*/modules.dep. The only accepted values for modprobe as it stands must be aliases defined in depmod/config.c or /etc/modules.conf, or modules listed in modules.dep. modules.dep could be trimmed, either by using an external post-processing utility, or by modifying depmod itself, before users get a chance to interact with kerneld. -- 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.