Re: Kernel-loadable Root Kits

From: Krzysztof Zaraska (
Date: 09/08/01

Date: Sat, 8 Sep 2001 20:07:14 +0200 (CEST)
From: Krzysztof Zaraska <>
To: D J Hawkey Jr <>

On Sat, 8 Sep 2001, D J Hawkey Jr wrote:

> On Sep 08, at 04:24 PM, Krzysztof Zaraska wrote:


> Except for a ctime change on /tmp (or wherever), you're right.
But activity in /tmp is normal and will be ignored by tripwire, right?

> > attacker out. Also, someone doing kldstat could see the trojan (if it's
> > not stealth). So this attack scenario is useful only if:
> >
> > (i) machine has long uptime (no power failures etc.)
> > (ii) no one does kldstat (assuming module is not stealth)
> >
> > Condition (ii) may be simply eliminated by adding kldstat to /etc/security.
> Again, true enough.
It came to me later that a skilled attacker may create a trojaned version
of some real module, say linux.ko and play with me like that:
# kldunload linux.ko
# kldload /tmp/linux.ko
# rm /tmp/linux.ko

If the trojaned modules has _exactly_ the same length as original it will
not be detectable with kldstat. But this may be somewhat difficult to
achieve. Anyhow, doing kldstat in /etc/security every night and checking
the results won't hurt you :).

> I've added quite a bit of stuff to /etc/security.
If it doesn't affect your security will you tell us what checks do you

> > We may also consider adding a feature to kldload to load only modules
> > from under /modules but I'm afraid this may be circumvented by attacker
> > fetching her own kldload. A better way would be to implement an
> > appropriate lock in kernel code but I don't know if it's possible.
> The first pro'lly isn't worth the effort.
> You lost me with the last bit; a lock to determine or do what, prevent
> userland 'kldload's? This would seem to be a Good Thing(tm), but how do
> you lock the lock - or would this be a kernel build-time option?
A kernel option that would do some extra checks with kldload(2) or
underlying functions. For example, the simplest thing would be to make
sure that the module is loaded from under /modules, since that tree is
static and watched by tripwire as you said.

Or, something LIDS-like.

Or, the M$ way: check the cryptographic signature of the module (IIRC they
sign drivers). You build the kernel and modules at one time usually. You
generate a new key pair, sign all the binaries, build the public key into
the kernel and destroy the secret key (or store it on the floppy and keep
in safe, but remove it from the protected machine). If someone tries to
load module with incorrect signature the module is rejected. If you (=the
sysadmin) want to add a new driver you use your key kept in safe or you
rebuild the whole system in case you destroyed the key. The attacker does
not have access to the secret key so she'd have to do a complete kernel
rebuild and system restart. And something like that would leave lots of
traces. Since all keys are in this scheme may be one-time the danger of
secret key theft may be eliminated.

Of course cryptographically verifying modules would eat some time, but you
don't load them all the time. And I think this idea would be possible to

> > As for the question of locating the trojan code in memory my (unverified
> > and possibly not implementable since I'm not a kernel hacker) idea is:
> > read the module code by /proc or otherwise, fill all data area with 0's
> > and compare MD5 checksums.
> Compare against what, and when? I don't follow you here, either.
Okay. You have code in executable (module) file and code in memory. These
should be the same, since IIRC code is first loaded from file to memory
and then executed and code pages are locked read-only. At build time you
calculate hash of the code in the file and store into database. Then at
runtime you read the proces/module/kernel code from RAM and compare it
against the file on disk (which is watched by tripwire anyhow) or
calculate the hash and compare against build-time database.
> All in all, it seems to me a kernel that needs no KLD modules, and denies
> all KLD loading, would be the easiest and most effective solution.

However, I can see an exception. At least in Linux world (where i come
from ;)) some time ago there were proprietary device drivers (sound cards,
IIRC) distributed as compiled modules. So you needed module support. There
may be a similar situation in the future, that say some SuperHardware Inc.
releases it's new 10Gbit ethernet adapter giving away the compiled drivers
as modules and not releasing the source code nor the hardware
specifications. In this case you need module support, at least at boot


To Unsubscribe: send mail to
with "unsubscribe freebsd-security" in the body of the message

Relevant Pages

  • Re: [Ksummit-2010-discuss] checkpoint-restart: naked patch
    ... of checkpoint/restart code is relatively self-contained. ... 20k lines of code is less than many pieces of the kernel. ... It's less than one of the simpler DRM graphics drivers -- i915: ... Perhaps a more fair comparison might be to compare ...
  • Re: [Full-disclosure] Microsoft GhostBuster Opinions
    ... this is not just like tripwire. ... >>and reporting false data to tripwire then tripwire can run along merrily ... This is why booting to a trusted kernel ...
  • Crashes on machines running tripwire
    ... tripwire includes some kind of kernel module that it uses when it is ... If indeed tripwire is what is "tripping up" this system, ... Kernel panic: Aiee, killing interrupt handler! ...
  • Re: [Full-disclosure] Microsoft GhostBuster Opinions
    ... On Thu, 17 Mar 2005, Dave King wrote: ... > a known good kernel could yeild incorrect results if the kernel has been ... A similar result can be had using tripwire on the system ... failing system that reboots or blue screens every few weeks rather then ...
  • Re: LKM support (Was: Re: possible compromise or just misreading logs)
    ... >> there is no way tripwire can be assured it is verifying the binary it ... >> asks the kernel for information about. ... If you get a root compromise so that a KLM can be ... I think tripwire makes it very ...