On November 7 Scott Barman asked about LD_LIBRARY_PATH and
other LD paths and linkage options affecting access to shared libraries
(Message inbox:287)
From: Scott Barman <scott @
Disclosure .
COM>
To: firewalls @
GreatCircle .
COM
Subject: Changing shared libraries and how is ld.so finding real libraries?
>
>Gee... this started out as a question and, after some investigation, has
>evolved into "what the heck is it doing?" Let's start with the original
>question:
>
> Now that the advisory is out regarding telnet and resetting
> the LD_LIBRARY_PATH environment variable I have a question:
>
> Is it possible for someone who has acquired unauthorized
> access to a system using an ordinary userid to upload in their
> own copy of libc.so.*, change LD_LIBRARY_PATH (or LD_RUN_PATH)
> so that /bin/login dynamically links with their hacked version
> rather than the one /usr/lib?
>
>I decided to do some investigating. Under Solaris 2.4 on a SPARC 1000E,
>I set up a "simulated" environment by creating some empty files that had
>the name of libraries under /tmp and tried to run the login program.
>The following is what I did:
>
> cd /usr/lib
> foreach i (lib*.so*)
> echo -n > /tmp/$i
> end
> cd security <--- hmmm this was an intersting find!
> foreach i (*)
> echo -n > /tmp/$i
> end
> setenv LD_LIBRARY_PATH /tmp
> setenv LD_RUN_PATH /tmp
> /usr/bin/login
>
>The login program seemed to work fine. It prompted me for my userid and
>password... no problems. In fact, any setuid or setgid program (ps
>and mail, for example) ran with no problems. Others, such as ls and
>examination of the output from nm and strings). But even with my stubs
>Can anyone enlighten me as to what is happening?
>
>TIA
>
>scott barman
>--
>scott barman DISCLAIMER: I speak to anyone who will listen,
>scott @
disclosure .
com and I speak only for myself.
>barman @
ix .
netcom .
com
I suspect is whats going on here is that either a LD_PRELOAD_PATH
is in use OR whats possibly closer to the truth that CERTAIN programs in SUNOS
and Solaris are linked statically to assist in recovering AFTER a
disaster involving shared libraries. Usually while working around at the
different OS vendors, I found them to follow this policy.
I know SUN did at one time
and according to one of the founders of microport(business associate) this
was also done(with the originals of Microport unix), I havent verified
ANY other OS that uses shared libs for this property so I dont know if it
holds true.
. I suggest you look mostly at the programs in
/usr/sbin(Standalone BINaries?? :) and run truss against them to verify WHICH
libs are REALLY being accessed, truss will tell you that.
You can also tag EVERY OS access with truss..
have FUN
kelly
p.s. Round about Solaris Version 2 Solaris programs involving the network
lost the ability to ever be linked statically again because of the getxx
routines I worked several SUN customers on the issue AND
found the BUG ids, that had been filed by a then current coworker and friend
while he was working client side kerberos checkout for SUN, while I DONT
agree with the reasons(sensitive binaries should ALWAYS be linked statically
particulary when the code handles information that has been classified)
I do recall that SOME binaries had at one point before being found and fixed
some hardcoded internal paths.
Follow-Ups:
References:
|
|
