Announcement: Solaris loadable kernel module backdoor
plasmoid
and FreeBSD loadable kernel module backdoors the first public loadable
kernel module backdoor for Solaris.
The module features:
- File hiding
- File content and directory hiding
- Switch to toggle file content and directory hiding
- Process hiding (structured proc)
- Promiscous flag hiding
- Converting magic uid to root uid
- Execution redirecting
It has been successfully tested on the following operating systems:
Solaris7 x86 / sparc / ultrasparc
Solaris 2.6 ultrasparc
The module can be directly downloaded from
--- http://www.infowar.co.uk/thc/files/thc/slkm-1.0.tar.gz
A complete documentation of the kernel module's functions can be found in
my article "Attacking Solaris with loadable kernel modules" at
--- http://www.infowar.co.uk/thc
Regards,
Plasmoid / THC
http://www.infowar.co.uk/thc
http://www.pimmel.com
Rainer Link
[cut]
> A simple approach for Linux would be something like this:
[cut]
> Any other ideas on preventing untrusted modules from being loaded or replaced
> and loaded as an existing 'trusted' module?
Well, one of the key features of the Linux Intrusion Detection System
Patch (imho the name is a little bit misleading) is "Modules protection:
Lock module insertion/removing. After your modules inserteds, you can
lock any other insmod/rmmod by issuing a echo 1 >
/proc/sys/lids/lock_modules"
See http://www.soaring-bird.com.cn/oss_proj/lids/
HTH
best regards,
Rainer Link
--
Rainer Link, eMail: lin...@fh-furtwangen.de, WWW: http://rainer.w3.to/
Student of Communication Engineering/Computer Networking, University of
Applied Sciences,Furtwangen,Germany,http://www.ce.is.fh-furtwangen.de/
Keith Owens
ped...@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.
Marc Esipovich
> 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...
Steven Alexander
From: Marc Esipovich <ma...@MUCOM.CO.IL>
To: <BUG...@SECURITYFOCUS.COM>
Sent: Wednesday, December 22, 1999 3:20 AM
Subject: Re: Announcement: Solaris loadable kernel module backdoor
> > With the proliferation of these types of backdoors, is there any way to
> > prevent your 'r00t3d' box from being backdoored?
Not completely. Being root means they can change almost anything. One
helpful thing is to install a progrm such as tripwire that stores checksums
of your files. However, tripwire can also be duped into believing
everything is alright(perhaps by modifying the kernel).
Another idea would be to store copies of /bin, /usr/bin, /usr/sbin,
/sbin,etc. on a cd-rom drive and backup up from those frequently, need it or
not. This will ensure that if any of these is tampered, an original will be
restored on a regular basis.
> 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.
Often, you can't. UNIX users have had this problem for awhile because of
loadable kernel modules and because you can recompile the kernel.
Recently, Windows NT users have begun to face the same problem(see Phrack55)
because there are are now known ways to patch the NT kernel. See
www.phrack.com and www.cell2000.net/security/ for more information. I have
source code(C++) for a program that can add one of the described patches and
remove both of them from an sp3 kernel under NT.
-steven