> With the proliferation of these types of backdoors, is there any way to
> prevent your 'r00t3d' box from being backdoored?
A few ways, it really depends weather you're prepared for it or not.
>
> A simple approach for Linux would be something like this:
>
Not so simple, it seems.
> 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.
>
It has been discussed on the Linux kernel list some time ago.
(or some other list?)
> kmod would check the MD5 sum before loading the requested module, if it didn't
> match the in-kernel list, don't allow it.
>
It can be tricky to implement in Linux, Solaris uses a slightly different
approach, all relocation and tuning of a module before it's actually
linked into the kernel are done inside the kerenl, unlike Linux, in which,
insmod does most of the work.
> 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.
>
The truely paranoid, prepare, beforehand. the truely paranoid disable
every single feature on the system they don't actually need.
ElGamal is more appropriate in this case rather than MD5, as discussed on
the list.
Even if you do disable untrusted modules, or modules in general, you can
still insert a module, or at least 'code', if you have write access to
/dev/[k]mem (as you already have root) , you can disable that, but it
would cause many programs to break, especially if your system doesn't have
procfs.
The approach would be applicable on a kernel which you have sources of,
it is still possible to modify a binary kerenl image to wipe out
/dev/[k]mem, but it's a nasty thing to do.
There are also other ways of writing directly, even if /dev/[k]mem is not
present, ioports, DMA...
Ideally, you will prepare (offsite) such a kernel and modules and put them
on read-only media, such as CDROM.
Basically it comes down to this, can you trust your own kerenl?...
you wake up one morning, read an article about backdoor kerenl modules,
and quickly run off to fix your system, at that point, how can you tell
you're not already infected by such a module? when you can't trust your
kernel, you can't trust anything on your entire system system.
> Any other ideas on preventing untrusted modules from being loaded or replaced
> and loaded as an existing 'trusted' module?
Take a look at Silvio Cesare's excellent article on injecting a kernel
module in systems which lack or disable module support. (don't have the
URL handy, sorry).
Sorry for this 'a little too verbose explentation',
Marc Esipovich.
--
root is only a few clicks away...
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:22:58 PDT