Bugtraq mailing list archives
Re: Announcement: Solaris loadable kernel module backdoor
From: kaos () OCS COM AU (Keith Owens)
Date: Thu, 23 Dec 1999 11:36:22 +1100
On Tue, 21 Dec 1999 14:33:50 -0800, pedward () WEBCOM COM wrote:
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.
kmod does not load modules. It starts a kernel thread and invokes modprobe. modprobe runs /etc/modules.conf and the the dependency chain then loads anywhere between zero and n modules. All of this work is in user space and it is all outside kernel control.
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.
At which point crackers just trojan the modprobe and insmod binaries. A chain is only as secure as its weakest link.
Any other ideas on preventing untrusted modules from being loaded or replaced and loaded as an existing 'trusted' module?
As long as any OS allows root to run user space utilities to modify the OS, the weak link is the lack of kernel support for checking that *all* binaries run by a privileged user are secure. There is no point building checks into modutils when any cracker running as root can run their own binary or LD_PRELOAD an existing binary. The day that you can boot a Linux kernel and stop root from changing anything and stop them using tricks like LD_PRELOAD, that is the day you can start trusting your user space utilities. And when you have a system like that, modutils will be changed to verify modules before loading. Of course by then it is probably irrelevant, a system which is that secure will not let anyone create rogue modules in the first place because they cannot update the filesystem. Adding a check to modutils without securing root's environment only raises the bar 0.5 cm. Any half competent cracker will switch to trojan modutil binaries and bypass the check. IMHO, building checksum support into modutils is fake security. Keith Owens, modutils maintainer.
Current thread:
- Re: SSH 1 Why?, (continued)
- 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)
- More details on the WU-FTPD configuration vulnerability. suid (Dec 21)
- Microsoft Security Bulletin (MS99-058) Aleph One (Dec 21)
- Microsoft Security Bulletin (MS99-061) Aleph One (Dec 21)