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 () perryat_private System Architecture Think Blue. /\
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:22:42 PDT