[25142] in bugtraq
Re: An alternative method to check LKM backdoor/rootkit
daemon@ATHENA.MIT.EDU (Karsten W. Rohrbach)
Thu Apr 18 17:23:38 2002
Date: Thu, 18 Apr 2002 15:16:45 +0200
From: "Karsten W. Rohrbach" <karsten@rohrbach.de>
To: Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>
Cc: Paul Starzetz <paul@starzetz.de>, Wang Jian <lark@marsec.net>,
bugtraq@securityfocus.com
Message-ID: <20020418151645.C50564@mail.webmonster.de>
Mail-Followup-To: "Karsten W. Rohrbach" <karsten@rohrbach.de>,
Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>,
Paul Starzetz <paul@starzetz.de>, Wang Jian <lark@marsec.net>,
bugtraq@securityfocus.com
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature"; boundary="kVXhAStRUZ/+rrGn"
Content-Disposition: inline
In-Reply-To: <87g01ux9qg.fsf@CERT.Uni-Stuttgart.DE>; from Weimer@CERT.Uni-Stuttgart.DE on Thu, Apr 18, 2002 at 12:04:39AM +0200
--kVXhAStRUZ/+rrGn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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.
>=20
> 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.
=2E..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=3Dallow-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
--=20
> 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.n=
et/
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 B=
F46
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. 1=
0x
--kVXhAStRUZ/+rrGn
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE8vsc9M0BPTilkv0YRAnbaAKDD4V5sHqr7m0EkcBLE1RPX+bxDzQCfW8/v
SLe0w8xJDh9yl6LLXC200u8=
=QLpF
-----END PGP SIGNATURE-----
--kVXhAStRUZ/+rrGn--
