From owner-freebsd-security Tue Jul 27 1:38:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id AF73814F40; Tue, 27 Jul 1999 01:38:12 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id EAA15096; Tue, 27 Jul 1999 04:37:08 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Tue, 27 Jul 1999 04:37:08 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: jkoshy@FreeBSD.org Cc: freebsd-security@FreeBSD.org Subject: Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? ) In-Reply-To: <199907270304.UAA57529@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 26 Jul 1999 jkoshy@FreeBSD.org wrote: > > Another cool attack on this mechanism is if the binary uses shared > > libraries: modify LD_LIBRARY_PATH so that its favorite shared library is > > your own version of the library, that proceeds to dump the entire > > application to disk when executed. > > Yes, it is certainly a subtle attack. I wonder if shared libs aren't more > trouble than gain. From the point of view of pluggable application code (PAM, crypto, etc) they are a wonderful boon. From the point of view of clear boundaries between bodies of executable code and traditional concepts of programs and processes, they certainly muddy the water. We've seen a number of attacks on NT and Windows based on centralized OS management of shared libraries--I think our mechanism of driving it from the user side works better, but one does have to be careful of "features" like LD_LIBRARY_PATH. It enables things like SOCKS proxy code without modifying the application, but also encourages this muddying. The real answer, as someone pointed out, may be to avoid trying to break out of the traditional UNIX uid-based protection domains: doing so seems only to cause angst :-). Moving towards a model of carefully audited and well-defined IPC between different protection domains might be better. For example, instead of using setuid applications and relying on a series of hacks to prevent debugging, shared libraries, etc, instead having daemons that listen on IPC channels (i.e., UNIX domain sockets or TCP ports, POSIX FIFOs, etc) in well-known locations. For example, a password daemon listening on /var/run/auth/passwd_socket that takes advantage of the local credential passing to authenticate the connection, and then provides password-related services via carefully audited LPC code. Once this is done, suddenly you don't have to audit the entire application, only its communication code, and you don't have to worry about the mixed credentials from setuid. Of course, programs like sendmail have shown that it's possible to really botch a communications protocol implementation, but part of the problem there is the text-based interface and complication of the issue. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message