ldd is not honoring LD_LIBRARY_PATH

[Carmelo AMOROSO]

On 10/10/2011 9.12, u-uclibc-y2lt at aetey.se wrote:
> Carmelo,
> 
> On Fri, Oct 07, 2011 at 03:26:49PM +0200, Carmelo AMOROSO wrote:
>> using the ldd implementation based on ld.so tracing by the environment
>> variable LD_TRACE_LOADED_OBJECTS, LD_LIBRARY_PATH is not taken into
>> account. So it could not found some libraries installed into a non
>> standard path.
> 
> I guess it has to do with the security implications arising when you
> try to figure out the dependencies of the program by running it.
> 
> http://www.google.se/search?q=ldd+vulnerability
> 
>> This is why the environment passed to the program is hard-coded
> 
> This makes it harder to exploit certain social engineering scenarios,
> I guess.
> 
>> The simplest implementation of ldd could be
>> LD_TRACE_LOADED_OBJECTS=1 $1
> 
> See above, that would be an unsafe tool. Activities of exploring a file
> and of running it should be isolated from each other.
> 
> Regards,
> Rune
> 
> 

Hello,
thanks for the hints. I've understood that most of the problems is due
the fact that an app could be linked against a different ld.so that
could maliciously execute the code even if it is expected to trace
dependencies only.

glibc ldd script indeed force to use the GNU loader /lib/ld-linux.so.

We now fortunately have the opportunity to run uClibc ld.so in
stand-alone mode as well, so this revised implementation should be safe.

I'll post a new version of the patch.

Thanks,
Carmelo