On 10/10/2011 9.12, [email protected] 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 _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
