Date: Mon, 15 Oct 2001 17:35:50 -0400 (EDT) From: "Andrew R. Reiter" <arr@watson.org> To: Krzysztof Zaraska <kzaraska@student.uci.agh.edu.pl> Cc: security@FreeBSD.ORG Subject: Re: Recent major changes in the NetBSD audit system Message-ID: <Pine.NEB.3.96L.1011015171706.1621A-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0110152313090.528-100000@lhotse.zaraska.dhs.org>
next in thread | previous in thread | raw e-mail | index | archive | help
What I meant by being flawed is that I look at from the perspective of how easy it would be to bypass the system, which given a kernel module would not be too difficult. I would be able to intercept the system calls and audit their arguments and return whatever information I please. Tripwire, atleast the last version I ran, essentially relied on the fact that the kernel's information was valid and was not tampered with, therefore allowing one to hide changes to monitored files or directories. Monitoring system file changes, if you think about it, can really extend all the way back to monitoring in kernel function calls. How can one really be certain that a call to read() is really executing the code found at the sysent[SYS_read].sy_call pointer? You could keep a valid list of addresses somewhere read-only (floppy?) and compare the functions nightly... however, this does not stop one from implementing a backdoor that provides a 7-byte jump overwrite -- keeping the address in the sy_call pointer the same, but changing the function itself. This would bypass the check. I started to tinker with doing function call checksumming -- essentially doing checks of the function data itself, but #1 I was losing sight of my end goal (monitoring system files) and #2 started worrying about the overhead this would cause us. Each checksum validation would most likely have to occur at the time of the functiion call and that would be nuts. I haven't thought about other ways to do this in a good manner... Im sure others have. Anyone want to chime in? Andrew On Mon, 15 Oct 2001, Krzysztof Zaraska wrote: :Could you explain this a little more in detail? If tripwire-like solutions :are flawed, how should it work then? : :Thanks in advance, : :Krzysztof : : *-------------................................................. | Andrew R. Reiter | arr@fledge.watson.org | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead 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.NEB.3.96L.1011015171706.1621A-100000>