Date: Sat, 8 Sep 2001 20:07:14 +0200 (CEST) From: Krzysztof Zaraska <kzaraska@student.uci.agh.edu.pl> To: D J Hawkey Jr <hawkeyd@visi.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Kernel-loadable Root Kits Message-ID: <Pine.BSF.4.21.0109081905250.1015-100000@lhotse.zaraska.dhs.org> In-Reply-To: <20010908102211.A77764@sheol.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 8 Sep 2001, D J Hawkey Jr wrote: > On Sep 08, at 04:24 PM, Krzysztof Zaraska wrote: [...] > Except for a ctime change on /tmp (or wherever), you're right. But activity in /tmp is normal and will be ignored by tripwire, right? [...] > > attacker out. Also, someone doing kldstat could see the trojan (if it's > > not stealth). So this attack scenario is useful only if: > > > > (i) machine has long uptime (no power failures etc.) > > (ii) no one does kldstat (assuming module is not stealth) > > > > Condition (ii) may be simply eliminated by adding kldstat to /etc/security. > > Again, true enough. It came to me later that a skilled attacker may create a trojaned version of some real module, say linux.ko and play with me like that: # kldunload linux.ko # kldload /tmp/linux.ko # rm /tmp/linux.ko If the trojaned modules has _exactly_ the same length as original it will not be detectable with kldstat. But this may be somewhat difficult to achieve. Anyhow, doing kldstat in /etc/security every night and checking the results won't hurt you :). > I've added quite a bit of stuff to /etc/security. If it doesn't affect your security will you tell us what checks do you recommend? > > We may also consider adding a feature to kldload to load only modules > > from under /modules but I'm afraid this may be circumvented by attacker > > fetching her own kldload. A better way would be to implement an > > appropriate lock in kernel code but I don't know if it's possible. > > The first pro'lly isn't worth the effort. > > You lost me with the last bit; a lock to determine or do what, prevent > userland 'kldload's? This would seem to be a Good Thing(tm), but how do > you lock the lock - or would this be a kernel build-time option? A kernel option that would do some extra checks with kldload(2) or underlying functions. For example, the simplest thing would be to make sure that the module is loaded from under /modules, since that tree is static and watched by tripwire as you said. Or, something LIDS-like. Or, the M$ way: check the cryptographic signature of the module (IIRC they sign drivers). You build the kernel and modules at one time usually. You generate a new key pair, sign all the binaries, build the public key into the kernel and destroy the secret key (or store it on the floppy and keep in safe, but remove it from the protected machine). If someone tries to load module with incorrect signature the module is rejected. If you (=the sysadmin) want to add a new driver you use your key kept in safe or you rebuild the whole system in case you destroyed the key. The attacker does not have access to the secret key so she'd have to do a complete kernel rebuild and system restart. And something like that would leave lots of traces. Since all keys are in this scheme may be one-time the danger of secret key theft may be eliminated. Of course cryptographically verifying modules would eat some time, but you don't load them all the time. And I think this idea would be possible to implement. > > As for the question of locating the trojan code in memory my (unverified > > and possibly not implementable since I'm not a kernel hacker) idea is: > > read the module code by /proc or otherwise, fill all data area with 0's > > and compare MD5 checksums. > > Compare against what, and when? I don't follow you here, either. Okay. You have code in executable (module) file and code in memory. These should be the same, since IIRC code is first loaded from file to memory and then executed and code pages are locked read-only. At build time you calculate hash of the code in the file and store into database. Then at runtime you read the proces/module/kernel code from RAM and compare it against the file on disk (which is watched by tripwire anyhow) or calculate the hash and compare against build-time database. > All in all, it seems to me a kernel that needs no KLD modules, and denies > all KLD loading, would be the easiest and most effective solution. Definitely. However, I can see an exception. At least in Linux world (where i come from ;)) some time ago there were proprietary device drivers (sound cards, IIRC) distributed as compiled modules. So you needed module support. There may be a similar situation in the future, that say some SuperHardware Inc. releases it's new 10Gbit ethernet adapter giving away the compiled drivers as modules and not releasing the source code nor the hardware specifications. In this case you need module support, at least at boot time. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0109081905250.1015-100000>