[13061] in bugtraq
Re: Announcement: Solaris loadable kernel module backdoor
daemon@ATHENA.MIT.EDU (pedward@WEBCOM.COM)
Wed Dec 22 16:01:58 1999
Content-Type: text
Message-Id: <199912212233.OAA15676@eris.webcom.com>
Date: Tue, 21 Dec 1999 14:33:50 -0800
Reply-To: pedward@WEBCOM.COM
From: pedward@WEBCOM.COM
X-To: plasmoid@pimmel.com
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.LNX.4.10.9912202342090.26215-100000@oops.spline.inf.fu-berlin.de> from "plasmoid" at Dec 20,
99 11:43:46 pm
With the proliferation of these types of backdoors, is there any way to
prevent your 'r00t3d' box from being backdoored?
A simple approach for Linux would be something like this:
At boot, compile the list of modules that are 'known good' (for the sake
of argument, it's the /lib/modules/x.y.z), then write the list, with
MD5 checksums, to a write once /proc interface to kmod.
kmod would check the MD5 sum before loading the requested module, if it didn't
match the in-kernel list, don't allow it.
For the write once, you'd have a 0600 /proc entry, that upon writing a
^D, it would change it to 0000.
For the really paranoid, at compile time you could tar up all the modules and
create the MD5 sum of that, store it in the kernel at some spot, and modify
the module utils to read tarfiles. If the MD5 sum of the tarfile doesn't
match the compiled in list, you can't load the module.
Any other ideas on preventing untrusted modules from being loaded or replaced
and loaded as an existing 'trusted' module?
--Perry
>
> I'd like to announce in addition to the two THC articles covering Linux
> and FreeBSD loadable kernel module backdoors the first public loadable
> kernel module backdoor for Solaris.
>
> Regards,
> Plasmoid / THC
> http://www.infowar.co.uk/thc
> http://www.pimmel.com
>
--
Perry Harrington Director of zelur xuniL ()
perry@webcom.com System Architecture Think Blue. /\
