Re: An alternative method to check LKM backdoor/rootkit

["Karsten W. Rohrbach" <karsten () rohrbach de>]

Florian Weimer(Weimer () CERT Uni-Stuttgart DE)@2002.04.18 00:04:39 +0000:
> I agree.  You can never be sure which kernel you are running.  An
> attacker could have placed a modified kernel on a swap device (which
> excludes this very area from being used as swap space), and tweaked
> the boot loader to load the modified kernel.
>
> Using this approach, the modified kernel image can be made completely
> invisible easily, and it still survives reboot.  Such a modification
> is very hard to spot even during an offline analysis, and the
> checklists I've seen so far do not address this problem at all.

...which implies that the kernel sitting in the swap partition has a
loader hook to be loadable, thus it has a pattern that can be found.
this pattern should be sufficiently non-ambiguous enough, to recognize a
fake kernel from swapped pages.

a different approach i know from systems with increased security
standards is clearing the swap, block by block, in the shutdown sequence.
since linux provides swapoff(2) instrumentation this would be very easy to
implement in the init scripts. dd(1) and mkswap(8) are your friends ;-)

a different approach would be adding signature checks to the loader
that get executed every boot time. to sign a kernel for boot
"authorization", you must sign it with an encrypted key, requiring
authentication to the signing system first (pgp style). to circumvent
this, one must have to install a new loader (lilo, grub, whatever) which
might be disallowed at run time thorugh kernel instrumentation. imagine
a kernel option "hda=allow-sec0mod" or similar. using this setup, also
the loader itself can be checked by itself at boot time for integrity
reasons.

just a few thoughts,...

regards,
/k

-- 
> Love does not make the world go around, just up and down a bit.
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE  DF22 3340 4F4E 2964 BF46
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists. 10x

Attachment: _bin
Description: