Date: Mon, 08 Dec 2003 09:31:55 -0800 From: Steve Francis <steve@expertcity.com> To: jan.muenther@nruns.com Cc: Roger Marquis <marquis@roble.com> Subject: Re: possible compromise or just misreading logs Message-ID: <3FD4B58B.9020308@expertcity.com> In-Reply-To: <20031208164804.GA92121@ergo.nruns.com> References: <20031207200130.C4B1216A4E0@hub.freebsd.org> <Pine.GSO.4.58.0312081045300.15156@mail.ilrt.bris.ac.uk> <20031208123501.GA87554@ergo.nruns.com> <20031208160428.DDF8FDAE9A@mx7.roble.com> <20031208164804.GA92121@ergo.nruns.com>
next in thread | previous in thread | raw e-mail | index | archive | help
jan.muenther@nruns.com wrote: >>>Apart from that, there are even tools (LKM based) which spoof MD5 checksums. >>> >>> >>Wouldn't effect tripwire. In addition to MD5 you'd need to spoof >>snefru, crc32, crc16, md4, md2, sha, and haval, and you''d have to >>spoof them for, at a minimum, the tripwire binary and its database >>file(s). >> >> > > > And just adding my voice to the "tripwire is good to run, but not a panacea" argument - if a machine gets a KLM loaded in a compromise, there is no way tripwire can be assured it is verifying the binary it asks the kernel for information about. Nothing to stop the compromised kernel returning the original binary for all requests, except for those needed to do Evil. If you get a root compromise so that a KLM can be loaded, all bets are off. Short of that, I think tripwire makes it very very hard to change files on a system w/o being detected. As long as that is all the faith you put in tripwire, and use to verify just that purpose and no more, its great, and it (or something like it, like AIDE) is essential.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FD4B58B.9020308>