[2395] in bugtraq
Re: a point is being missed
daemon@ATHENA.MIT.EDU (Mark D Riggins)
Fri Nov 10 19:48:55 1995
Date: Fri, 10 Nov 1995 12:01:29 -0500
Reply-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
From: Mark D Riggins <mdr@vodka.sse.att.com>
X-To: BUGTRAQ@CRIMELAB.COM
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM>
In-Reply-To: <199511091818.KAA06260@bingy.acs.uci.edu> from "Dan Stromberg -
OAC-DCS" at Nov 9, 95 10:18:51 am
I've read a little code on SVR4 to investigate and maybe help settle
this shared lib issue.
Here's what I found:
1) The LD_RUN_PATH option to the linker gives more lattitude than you
may be aware of.
The linker adds this path to the a.out at compile time. The
dynamic linker gives it precendence over any environment flags
such as LD_LIBRARY_PATH. So vendors could specify an
LD_RUN_PATH of /usr/add-on/lib:/usr/lib:/usr/ccs/lib to allow
extensibility w/o compromising security.
A properly set LD_RUN_PATH is as secure as a statically linked
binary because it will resolve all libraries from trusted
directories. As long as all necessary libraries are present,
there will be no means of attack. If the hacker gets
write-access to /usr/lib, you've been toast for a long time by
then.
I don't know, but assume that similar functionality exists on
other UNIX derivatives that support shared libs.
2) setuid files are not immune from LD_LIBRARY_PATH *if* they are executed
by the owner. The check is not made on the file permission bits,
it rather checks to see that getuid() == geteuid(). So if a
daemon running as real and effective root gets its environment
hosed, you're toast.
Also some seem to feel that read access to shared libraries is a
security problem. Why? Aren't these readily available for inspection
on many accessible hosts? If you see some other reason, please let me
know, I'm interesting in investigating it.
Mark Riggins
Secure Systems Engineering
AT&T Bell Labs
