4 ms·
> Second, ldd, the dynamic linker, can be manipulated into executing arbitrary code. ldd is not the dynamic linker, it's only a tool to debug the process of dy
by themulticaster 5y ago
> Second, ldd, the dynamic linker, can be manipulated into executing arbitrary code.
ldd is not the dynamic linker, it's only a tool to debug the process of dynamic linking. The dynamic linker is ld-linux.so (exact name depends on glibc version, architecture, etc.)
Also, I think the linked article [1] about the security of ldd is somewhat useless. The ldd(1) manpage [2] is very explicit about the security of ldd and tells you not to run ldd on untrusted executables:
> [...] Thus, you should never employ ldd on an untrusted executable, since this may result in the execution of arbitrary code.
It's a little amusing how the linked blog post explains how to create a malicious executable that runs arbitrary code when inspected with ldd, noting that "I researched this subject thoroughly and found that it's almost completely undocumented. I have no idea how this could have gone unnoticed for such a long time." and concluding with "Never run ldd on unknown executables!" - all while the manpage literally mentions that precise known limitation in the third paragraph!
To be fair, you could argue that this limitation is not widely known and people should be made aware of the risks of ldd, but on the other hand you can hardly criticize ldd when its manpage is that explicit about the issue.
[1] https://catonmat.net/ldd-arbitrary-code-execution https://catonmat.net/ldd-arbitrary-code-execution
[2] https://www.man7.org/linux/man-pages/man1/ldd.1.html https://www.man7.org/linux/man-pages/man1/ldd.1.html
- ghoward 5y agoAuthor here. Thank you for pointing out my mistake. I'll fix it.
- Hello71 5y agold isn't the dynamic linker either, it's the object linker. the name of the dynamic linker is ld.so or ld-linux.so. this is also documented in the ldd man page.
- eqvinox 5y agoFun fact: despite the library path and name, ld-linux.so is executable. Try running /lib64/ld-linux-x86-64.so.2 On your favorite Linux box. (Adjust path if needed for different architecture / distro.)
- cataphract 5y agoIn fact, /lib64/ld-linux-x86-64.so.2 is set as the interpreter of the dynamic executables, so executing ./dyn_exec ends up being equivalent to /lib64/ld-linux-x86-64.so.2 ./dyn_exec. The explicit form is sometimes useful, for instace if you want to execute the file with an interpreter other than the one specified in the executable, or if you want to pass one of the parameters that ld.so accepts.
- rkeene2 5y agoIt's also useful if you accidentally chmod -x chmod...
- eqvinox 5y agoSecure - and more useful - replacement: lddtree. Part of "pax-utils" or similar package on some distros. It's actually a shell script wrapper around scanelf (also pax utils), which reads the appropriate bytes from ELF files without just executing the ELF file.
- rkeene2 5y agoI usually just do: objdump -x <binary> | grep NEEDED but this is a great tip !
- colonwqbang 5y agoOften you need to find not only the soname but the actual .so file that is found and linked. This can be affected by environment variables like LD_PRELOAD and LD_LIBRARY_PATH. Unfortunately I don't know of a way to check this without ldd. If somebody knows of a tool that can do this without executing the binary, please share.
- eqvinox 5y agolddtree does handle LD_LIBRARY_PATH. It doesn't care about LD_PRELOAD though.
- ratmice 5y agoWhile you are technically correct, ldd is literally a bash script which runs ld-linux.so...
- throwaway09223 5y agold-linux.so's job is to link and run an executable. It's not a vulnerability that it runs executable it's been handed. If you run "ld-linux.so /bin/ls" you're just running "ls" There's no security issue with this behavior. It's an interpreter like any other - same as /usr/bin/python. The argument around ldd having a vulnerability is that it appears to be an introspective tool. It is not immediately obvious that it just executes "LD_TRACE_LOADED_OBJECTS=1 ld-linux.so /bin/ls" to print what the linker does during an actual, live linking operation. ldd documenting this fact to remind people seems reasonable to me. There are other tools like readelf which can inspect objects without executing their contents. Dynamic linking is, well, dynamic and it can depend on code executed at runtime -- so it is necessary to do so to get an accurate report of what will happen.