Date: Sat, 8 Sep 2001 16:24:23 +0200 (CEST) From: Krzysztof Zaraska <kzaraska@student.uci.agh.edu.pl> To: D J Hawkey Jr <hawkeyd@visi.com> Cc: deepak@ai.net, freebsd-security@FreeBSD.ORG Subject: Re: Kernel-loadable Root Kits Message-ID: <Pine.BSF.4.21.0109081554260.765-100000@lhotse.zaraska.dhs.org> In-Reply-To: <200109081052.f88AqRG30016@sheol.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 8 Sep 2001, D J Hawkey Jr wrote: > > System is violated, > > Root kit is installed, > > Root kit [binaries] are deleted from the machine. > > > > Solution: > > > > Reboot machine > > Rebooting won't necessarily fix anything. IIRC, one Linux rootkit > replaces a module with the backdoor. If the kernel needed that module > once, it'll need it again. It will fix if the trojan module is removed. See below. > > How does one DETECT that the root kit is there in the first place to know to > > reboot it? > > Tripwire. Not straightforward. Scenario described above suggested doing something like # kldload trojan.ko && rm /modules/trojan.ko So the only alert you may get from tripwire is that ctime of /modules is changed. However, I was able to do that: lhotse# kldstat Id Refs Address Size Name 1 2 0xc0100000 21e4f4 kernel 2 1 0xc0784000 12000 linux.ko lhotse# cp /modules/warp_saver.ko /tmp lhotse# kldload /tmp/warp_saver.ko lhotse# kldstat Id Refs Address Size Name 1 3 0xc0100000 21e4f4 kernel 2 1 0xc0784000 12000 linux.ko 3 1 0xc0832000 2000 warp_saver.ko So it's possible to load a kernel module not located under /modules. So if attacker does # kldload /tmp/trojan.ko && rm /tmp/trojan.ko tripwire won't find anything. I thing the original question was: how to find a trojaned module in memory if there's no relevant binary on disk? However, in case of deleting module binary a reboot removes the root kit and assuming that no other changes to system were made effectively locks 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. 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. 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. Tripwire for running binaries ;) All comments welcome. Regards, 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.0109081554260.765-100000>