Date: Sun, 14 Jun 1998 22:19:29 +0100 From: njs3@doc.ic.ac.uk (Niall Smart) To: dima@best.net, njs3@doc.ic.ac.uk (Niall Smart) Cc: security@FreeBSD.ORG, abc@ralph.ml.org Subject: Re: bsd securelevel patch question Message-ID: <E0ylKBV-0001IS-00@oak71.doc.ic.ac.uk> In-Reply-To: dima@best.net (Dima Ruban) "Re: bsd securelevel patch question" (Jun 14, 1:48pm)
next in thread | raw e-mail | index | archive | help
On Jun 14, 1:48pm, Dima Ruban wrote: } Subject: Re: bsd securelevel patch question > Niall Smart writes: > > On Jun 13, 11:03pm, Dima Ruban wrote: > > > > Why do they advocate protecting login and su if such protection can > > be trivially defeated using the same techniques we demonstrated in > > the attack on inetd? And why do they claim these features improve the > > security of a system "dramatically" if they can be bypassed so easily? > > > > What use are securelevels without propagating the immutable flag? > > The problem is - your patch doesn't fix anything. It just makes things more > complicated. > Example was already given, but here we go again: > You make text segment of a program that marked immutable being a read-only. > Excellent. In this case you need to make sure that such a process can't > be killed or basically can't receive any signals. And this breaks the > whole idea of signals. Because otherwise, being root, I can easily kill > such a process and start another one with a back door in it. > pid is not an issue - it can be easily faked to be the same as a target > process. This is not correct, the fix does not require the prevention of killing immutable processes. Its effectiveness relies on the ability to detect when a system daemon has died, and one other requirement noted below. There are a number of ways to achieve the first: - Kernel modifications which log whenever a process which has no controlling terminal dies. This is straightforward to achieve and covers all the important cases. It is even useful for non-security related reasons. Of course you can extend this patch to log whenever any particular pid dies. This is the recommended approach. - Never reuse PID's generated while the system was in secure level 0. Again, this is relatively easy to achieve, and prevents the replacement of daemons with trojans that have an identical pid, and the monitoring can be performed in userland. There is still the question of who monitors the death of the monitoring process. This is why the first idea is superior. One of the important implications of the fix is that it moves from the need to detect covert modification of the system daemons, which is obviously a critical need, to the need to detect when the daemons have been whacked using kill and then replaced. It is virtually impossible to detect the first type of abuse, and indeed I do not believe this kind of abuse should even be permitted. Detecting when a process dies is much easier. Also, if the immutable flag is used in the way I believe it should, then there is nothing the attacker can do to modify the logs generated when he replaces a daemon, nor can he prevent you from viewing them. I mentioned that there was one other way to defeat the patch: If the intruder can find a way to overflow an internal buffer inside the daemon then he can still make it execute arbitrary code. There are certain communication channels which are only between the root user and the system daemons which may therefore not be well protected in terms of buffer management. For example, parsing of configuration files. The only way of preventing against this style of attack is to either - ensure your buffers can't ever be overflowed by _anyone_, this is _always_ a good idea. - implement a capabilities-based security model; even this isn't fool-proof. Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0ylKBV-0001IS-00>