Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 9 Sep 2001 00:19:51 +0300
From:      Giorgos Keramidas <charon@labs.gr>
To:        Sansonetti Laurent <lorenzo@linuxbe.org>
Cc:        deepak@ai.net, freebsd-hackers@freebsd.org
Subject:   Re: Kernel-loadable Root Kits
Message-ID:  <20010909001951.A6949@hades.hell.gr>
In-Reply-To: <002f01c13871$8dc2d360$0201a8c0@teledisnet.be>; from lorenzo@linuxbe.org on Sat, Sep 08, 2001 at 04:21:29PM %2B0200
References:  <GPEOJKGHAMKFIOMAGMDIGEHGFHAA.deepak@ai.net> <002f01c13871$8dc2d360$0201a8c0@teledisnet.be>

next in thread | previous in thread | raw e-mail | index | archive | help
From: Sansonetti Laurent <lorenzo@linuxbe.org>
Subject: Re: Kernel-loadable Root Kits
Date: Sat, Sep 08, 2001 at 04:21:29PM +0200

> Hello,
> 
> > Short question:
> >
> > Is there a way to prevent the kernel from allowing loadable modules?
> 
> Yes, by hacking kldload(2).  You can also switch the secure level using
> sysctl.
>
> > With the advent of the kernel-loadable root kit, intrusion
> > detection has gotten a bit more complicated. Is there a _simple_
> > solution to detecting the presence of a kernel-based root kit once
> > it is running?
> 
> 1) scan the sysent table and check syscalls pointers (generally, rootkits
> intercepts syscalls)

This can get really "hairy".  To scan the syscall table, even if you
are 'root' and directly access /dev/mem you will have to use some
system calls to open(), read() and seek() into the /dev/mem device.
But those syscalls might be the intercepted ones: ouch!

Instead of worrying after the module has been loaded it's much safer
to run the kernel in securelevel>=1 when modules cannot be loaded
without a reboot to single-user mode.

-giorgos


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010909001951.A6949>