$ lddsafe /usr/bin/xcalc libXaw.so.7 => /usr/lib/libXaw.so.7 libXmu.so.6 => /usr/lib/libXmu.so.6 libXt.so.6 => /usr/lib/libXt.so.6 libSM.so.6 => /usr/lib/libSM.so.6 libICE.so.6 => /usr/lib/libICE.so.6 libc.so.6 => /lib/libc.so.6 ld-linux.so.2 => /lib/ld-linux.so.2 libuuid.so.1 => /lib/libuuid.so.1 libX11.so.6 => /usr/lib/libX11.so.6 libxcb.so.1 => /usr/lib/libxcb.so.1 libXau.so.6 => /usr/lib/libXau.so.6 libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 libdl.so.2 => /lib/libdl.so.2 libXext.so.6 => /usr/lib/libXext.so.6 libXpm.so.4 => /usr/lib/libXpm.so.4 libm.so.6 => /lib/libm.so.6
Some days ago we could all read that "ldd", a tool which prints shared library dependencies, should not be run on untrusted binaries. I read it first on Hacker News and later it hit Slashdot’s frontpage. In some operating systems, this is stated clearly in the man page for the program, while in others it’s not mentioned at all. I belonged to the camp that didn’t know about it and I was a bit surprised. I supposed ldd was doing its job by examining the binary file and not by running it setting some special environment variables.
A Hacker News user, anyway, pointed out something interesting. You can easily get information about the needed shared library dependencies for a program or library using "objdump", so I spent a few hours writing and tweaking a small script called lddsafe that prints almost the same information as "ldd" using "objdump" and avoiding the security problems, as it doesn’t have to run the program. Two major caveats at this point in time:
It requires bash and, more specifically, bash version 4 or later. I needed to use associative arrays to make the program reasonably fast and they are only available in bash 4.
It’s only been tested under Slackware Linux. However, bug reports and patches are welcome if it doesn’t run properly in other distributions.
Future improvements may include rewriting it in Perl so as not to require bash 4, knowing that Perl is present in most Unix systems.
A picture is worth a thousand words: