From owner-freebsd-hackers Sat Sep 8 17:49:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 07A3337B405 for ; Sat, 8 Sep 2001 17:49:07 -0700 (PDT) Received: from hades.hell.gr (patr530-b118.otenet.gr [195.167.121.246]) by mailsrv.otenet.gr (8.11.5/8.11.5) with ESMTP id f890n1A16337; Sun, 9 Sep 2001 03:49:01 +0300 (EEST) Received: (from charon@localhost) by hades.hell.gr (8.11.6/8.11.6) id f88LJqf06975; Sun, 9 Sep 2001 00:19:52 +0300 (EEST) (envelope-from charon@labs.gr) Date: Sun, 9 Sep 2001 00:19:51 +0300 From: Giorgos Keramidas To: Sansonetti Laurent Cc: deepak@ai.net, freebsd-hackers@freebsd.org Subject: Re: Kernel-loadable Root Kits Message-ID: <20010909001951.A6949@hades.hell.gr> References: <002f01c13871$8dc2d360$0201a8c0@teledisnet.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002f01c13871$8dc2d360$0201a8c0@teledisnet.be>; from lorenzo@linuxbe.org on Sat, Sep 08, 2001 at 04:21:29PM +0200 X-PGP-Fingerprint: 3A 75 52 EB F1 58 56 0D - C5 B8 21 B6 1B 5E 4A C2 X-URL: http://students.ceid.upatras.gr/~keramida/index.html Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG From: Sansonetti Laurent 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