Bugtraq mailing list archives
Re: Announcement: Solaris loadable kernel module backdoor
From: marc () MUCOM CO IL (Marc Esipovich)
Date: Wed, 22 Dec 1999 11:20:07 +0200
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...
Current thread:
- SSH 1 Why?, (continued)
- SSH 1 Why? Daniel P. Zepeda (Dec 14)
- Re: SSH 1 Why? Emiliano Kargieman (Dec 15)
- Re: SSH 1 Why? Emiel Kollof (Dec 15)
- Re: SSH 1 Why? Iván Arce (Dec 16)
- Re: SSH 1 Why? R. J. Wysocki (Dec 18)
- Groupewise Web Interface Sacha Faust Bourque (Dec 19)
- Re: Groupewise Web Interface Raymond Dijkxhoorn (Dec 20)
- Re: Groupewise Web Interface Bayard G. Bell (Dec 21)
- Announcement: Solaris loadable kernel module backdoor plasmoid (Dec 20)
- Re: Announcement: Solaris loadable kernel module backdoor pedward () WEBCOM COM (Dec 21)
- Re: Announcement: Solaris loadable kernel module backdoor Marc Esipovich (Dec 22)
- Re: Announcement: Solaris loadable kernel module backdoor Steven Alexander (Dec 23)
- Re: Announcement: Solaris loadable kernel module backdoor Rainer Link (Dec 22)
- Re: Announcement: Solaris loadable kernel module backdoor Keith Owens (Dec 22)
- Re: Groupewise Web Interface satherrl () MAILPOINT DSSRG CURTIN EDU AU (Dec 21)
- Norton Email Protection Remote Overflow (Addendum) Matt Conover (Dec 20)
- procmail / Sendmail - five bugs Michal Zalewski (Dec 23)
- Re: procmail / Sendmail - five bugs Rob Jones (Dec 20)
- Re: procmail / Sendmail - five bugs Michal Zalewski (Dec 22)
- FTPPro insecuities The Wall (Dec 27)
- serious Lotus Domino HTTP denial of service Alain Thivillon (Dec 21)