Date: Sat, 8 Sep 2001 10:22:11 -0500 From: D J Hawkey Jr <hawkeyd@visi.com> To: Krzysztof Zaraska <kzaraska@student.uci.agh.edu.pl> Cc: deepak@ai.net, freebsd-security@FreeBSD.ORG Subject: Re: Kernel-loadable Root Kits Message-ID: <20010908102211.A77764@sheol.localdomain> In-Reply-To: <Pine.BSF.4.21.0109081554260.765-100000@lhotse.zaraska.dhs.org>; from kzaraska@student.uci.agh.edu.pl on Sat, Sep 08, 2001 at 04:24:23PM %2B0200 References: <200109081052.f88AqRG30016@sheol.localdomain> <Pine.BSF.4.21.0109081554260.765-100000@lhotse.zaraska.dhs.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 08, at 04:24 PM, Krzysztof Zaraska wrote: > > 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. Well, "replaced" might be better phrasing, no? If the kernel needed it (as opposed to an user loading it), chances are it'll want it again. > > > 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. That'd raise my short-hairs; that tree ought to be [completely?] static. > 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. Except for a ctime change on /tmp (or wherever), you're right. > 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. Again, true enough. I've added quite a bit of stuff 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. 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? If I'm with you, it seems to me you'd also have to see that the kernel loads all the modules at boot that it would need to fulfill all runtime requirements, too, else it may load a trojan in the course of uptime. Either that, or build 'em into the kernel. > 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. > Tripwire for running binaries ;) > > All comments welcome. If 'kldload' logs [via syslogd], most of this activity would be traceable. Now, most crackers will sanitize the log(s), but that might leave tell-tail holes in time, too. One could log remotely, to [help] keep log integrity. 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. > Regards, > Kris Dave -- Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" 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?20010908102211.A77764>