Date: Tue, 27 Jul 1999 04:37:08 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> 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? ) Message-ID: <Pine.BSF.3.96.990727043024.15036D-100000@fledge.watson.org> In-Reply-To: <199907270304.UAA57529@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990727043024.15036D-100000>