Messages in this thread | | | Subject | Re: [linux-security] Malicious Linux modules (fwd) | Date | Wed, 15 Oct 1997 13:24:22 -0700 | From | Jim Dennis <> |
| |
> > olaf@bigred.inka.de (Olaf Titz) writes: > >>Loading modules lets potentially untrustworthy code into your trusted > >>environment so the modules need checked first. > >Modules operate on _the same_ trust level as the kernel itself. If a > >hacker can install a malicious module, he can as well install a > >malicious kernel. > > I think the difference is that in Linux (and most loadable module > systems), it's quite easy for an attacker to clandestinely load a > module. All they need to do is bring the .o file over, insmod it, and > then remove the .o file. The attacking module cloaks itself, and the > only trace left is in the kernel memory itself. Even that might not be > visible if the module is stealthy enough. You're in a lot of trouble > if you can't trust your kernel.
I believe the intent of 'securelevel' is to prevent this sort of problem (among several others).
What I don't know is if we're going to have a 'securelevel' feature that is compatible with any but the most strictly configured servers.
There's some discussion of implementing 'securelevel' as a bit field rather than as a simple, montonically increasing integer. In that scheme we might be willing to secure the system against some things (like chattr/immutable changes, and "new" loadable modules) while leaving some potential holes open (like ioperm). This would allow us to run X -- accepting the attendant risks.
I've heard that GGI would solve the problem of running X under securelevel 1 -- but none of us really know what sorts of other problems that *might* create.
I've heard some debate about kerneld (lkmd in FreeBSD?). Some have argued that it whould be given some dispensation at securelevel 1 but restricted to modules that are already in the dependencies table (depmod) or some other list.
This would give "almost" the same protection -- since the attacker would have to introduce a link to new module into the (presumably immutable) /lib/modules directory tree and run depmod (which need to update the presumably immutable dependencies table).
Presumably we'd completely disable this at securelevel 2 (i.e. kerneld is inappropriate for those systems -- compile a larger kernel and/or have a script do your insmod's prior to increasing the securelevel).
I also haven't seen a good, clear, list of which features (restrictions) are associated with each securelevel.
> > Installing a whole malicious kernel, as far as I know, requires > rebooting the machine to load the new kernel. A good sysadmin will > note when a machine reboots for no good reason and investigate. So > loadable modules make it easier to hack a running kernel. This isn't > big news, and shouldn't be considered a Huge Security Flaw. It does > give one pause, though.
There is the question of how you'll detect the system reboot. If you have a well-configured loghost -- which is more secure than the machine in questions (probably because it has more restricted trust relationships, no user accounts, and runs no services other than syslogd) -- than you can detect a failed heartbeat, and possible other tell tails (depending on how thorough your attacker it).
Short of having a null modem to the more secure system configured as the system console I don't see how you could ensure that your loghost will see the reboot.
(Once the system is rebooted with a rogue kernel than all evidence is up for grabs -- uptime can be changed, syslog messages can be forged, log files can be modified, etc.).
I suppose you might have a scheme where the system gets something like a kerberos ticket (or like the Netscape SSL server's requirement that a typist enter the passphrase to unlock the server key to start the SSL server). Under this scheme the system would be unable to start a given session server until someone logged in and typed the appropriate passphrase. The failure of this server to load would be a key that the system had been rebooted.
(Now the attacker has to install a ttysnooper for some period of time, long enough to steal the passphrase, BEFORE rebooting the system).
> It gets a bit trickier to clandestinely install a malicious module > that will survive a reboot - you have to put it in the filesystem > somewhere and ensure it's loaded at boot time. I imagine there is a > way to do this stealthily, but hacking the kernel image itself is > probably easier.
Actually it sounds pretty easy to hack the ext2fs code along with the kernel/modules and have that version of the ext2fs code hide data from user processes. It could probably even be done in such a way that unhacked ext2fs drivers would view these hidden data structures as bad blocks.
For example you might hide your data in "badblocks" and have a signature on the "badblock" that points to a "hidden inode table" (a small one). If your hacked ext2fs driver *actually it a badblock* where it looks for this signature it might cause a system lockup -- or some timeouts and retries. However a normal ext2 driver (from your rescue diskette or CD) wouldn't have any reason to question a few hundred badblocks on the system.
I'm not a programmer -- and particularly not a kernel hacker. However, it sounds easier to hide data on a disk than it does to play hide-and-seek in core.
-- Jim Dennis (800) 938-4078 consulting@starshine.org Proprietor, Starshine Technical Services: http://www.starshine.org PGP 1024/2ABF03B1 Jim Dennis <jim@starshine.org> Key fingerprint = 2524E3FEF0922A84 A27BDEDB38EBB95A
| |