2

Assume I perform ldd /bin/ls with the pthread library removed. I obtain

linux-vdso.so.1 (0x00007ffcc3563000)

libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f87e5459000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f87e5254000)
libc.so.6 => /lib64/libc.so.6 (0x00007f87e4e92000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f87e4c22000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f87e4a1e000)
/lib64/ld-linux-x86-64.so.2 (0x00005574bf12e000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007f87e4817000)
libpthread.so.0 => not found

The return code is zero. Is there a command returning an error in this case? Something similar to

#!/bin/bash
if [[ ! -z $(ldd ${target} | grep 'not found') ]]; then
   exit 1
fi
1

Take care with ldd on linux; it's just a bash script which, at least on older systems, will run the given program with LD_TRACE_LOADED_OBJECTS=1 in its environment.

This means that if the program has other interpreter than /lib{64,32}/ld-*, that program will be run with your target as its first argument, even if you didn't mean to do it. If you run ldd on an executable owned by some other user, that user will own you instead.

You can check what interpreter is defined in the ELF headers with readelf -l "$target" | grep interpreter.

On newer systems, ldd has been changed to pass the target as argument to an interpreter taken from a list of 'good' interpreters (eg. /lib64/ld-linux.so.2 target); I don't find that convincing, but it's up to you to make the determination if that's safe enough.

If you find all that acceptable, the simplest way to do it is:

if ldd "$target" | grep -q 'not found'; then
   echo >&2 "$target is missing dependencies"
   exit 1
fi

If called in 'trace mode' (as from ldd), the default dynamic loader on linux will always exit with a 0 status, and there's no way to change that via command line switches or environment variables; you'll have to change its source code.

  • See also CVE-2009-5064. – Stephen Kitt Nov 12 '18 at 13:39
  • Just out of curiosity, what would it take for you to find “that” convincing? – Stephen Kitt Nov 12 '18 at 14:13
  • Nothing -- ld.so is complex enough so that's no safe way to run in 'dry' mode with unknown binaries. Of course you won't find spectacular exploits against it, because it wasn't a real security issue in the first place, so it's not worth bothering with; no sysadmin worth their two bits would use ldd against random binaries. – qubert Nov 12 '18 at 14:23
  • From the ldd man page ... safer to use objdump -p /path/to/program |grep NEEDED instead. – RubberStamp Nov 12 '18 at 20:47
  • @RubberStamp compare the output of objdump -p /usr/bin/xeyes | grep NEEDED to ldd /usr/bin/xeyes. Shared objects depend on other shared objects. – qubert Nov 12 '18 at 21:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.