💾 Archived View for thrig.me › blog › 2024 › 06 › 13 › ldd-advice.gmi captured on 2024-08-18 at 18:18:01. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2024-06-16)

-=-=-=-=-=-=-

Unsolicited ldd(1) Advice

    $ ldd /usr/X11R6/bin/xterm
    /usr/X11R6/bin/xterm:
    /usr/X11R6/bin/xterm: Permission denied
    /usr/X11R6/bin/xterm: exit status 1

As you can see, ldd is broken on OpenBSD, so therefore OpenBSD is a terrible OS. I mean, who would break ldd?! A minor problem here is that ldd(1) may execute arbitrary code, and xterm has the set-group-id bit turned on, so may execute arbitrary code as some other user. Anyways, arbitrary code execution is bad, unless you're an attacker pretending to be a confused user who wants to trick root into running ldd on some binary that the attacker has been having weird library issues with.

   Security
       Be aware that in some circumstances (e.g., where the program
       specifies an ELF interpreter other than ld-linux.so), some
       versions of ldd may attempt to obtain the dependency information
       by attempting to directly execute the program, which may lead to
       the execution of whatever code is defined in the program's ELF
       interpreter, and perhaps to execution of the program itself.
       (Before glibc 2.27, the upstream ldd implementation did this for
       example, although most distributions provided a modified version
       that did not.)

       Thus, you should never employ ldd on an untrusted executable,
       since this may result in the execution of arbitrary code.  A
       safer alternative when dealing with untrusted executables is:

https://www.man7.org/linux/man-pages/man1/ldd.1.html

So one piece of ldd(1) advice might be: don't.

Alternatives

    objdump -p `which xterm` | grep NEEDED
    readelf -d `which xterm` | grep hare

However, object dumping and ELF reading tools may also have security vulnerabilities (elves are pretty complicated to parse), so maybe only poke at untrusted binaries on an isolated test system, or login as the user in question before having a look at the program they claim to be having trouble with. Also it's really easy to forget that ldd(1) may execute arbitrary code, so you may want to put in an alias that disables it by default (and says what wiki page to read as to why it is disabled) in a shared environment?