lkml.org 
[lkml]   [1997]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [linux-security] Malicious Linux modules (fwd)
Date
From
> 
> 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


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:1.472 / U:0.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site