Arbitrary Code Execution With "ldd"

pkrumins writes "The ldd utility is more vulnerable than you think. It's frequently used by programmers and system administrators to determine the dynamic library dependencies of executables. Sounds pretty innocent, right? Wrong! It turns out that running ldd on an executable can result in executing arbitrary code. This article details how such executable can be constructed and comes up with a social engineering scenario that may lead to system compromise. I researched this subject thoroughly and found that it's almost completely undocumented."

Comments

the bug is not in ldd

[FranTaylor]

If you had read the article closely you would understand that the bug is not in ldd, it is in the dynamic loader.

Re:the bug is not in ldd

[Timothy Brownawell]

If you had read the article closely you would understand that the bug is not in ldd, it is in the dynamic loader.

The bug is that ldd executes the dynamic loader, which is specified by the executable being inspected. So if the executable claims to use ~/bin/evil.so as a loader instead of the standard /lib/ld-linux.so, then ldd will execute ~/bin/evil.so.

Re:the bug is not in ldd

[marcansoft]

The bug is that ldd is trying to do the impossible: list dynamic dependencies for executables that it doesn't understand (more precisely: executables that don't use glibc and/or the standard linking mechanisms). The catch is that glibc's implementation offloads this task onto the dynamic linker, and whoever wrote ldd thought the rest of the world would be nice and follow ld-linux's environment variable convention with their dynamic loaders. And, of course, this completely violates the assumption that ldd treats its argument as data, and will not run code from it.

What ldd needs to do is realize that trying to be generic is futile, and either a) check for ld-linux and bail if otherwise, or b) become a real C app (using libbfd?) that can inspect the executable as data, which might gain it compatibility with other loaders if they follow the same ELF ABI for dependency specification. And under no circumstances actually call out to any untrusted code or libraries to do this.

Re:Another WIN in WINdows

[Fizzl]

http://www.dependencywalker.com/

Re:Another WIN in WINdows

[MyLongNickName]

Yup. I've used it. It is a very useful tool. Note that this is not something built into Windows.

Re:Another WIN in WINdows

[joebp]

depends.exe does exactly this and ships with the platform sdk.

Documented in ldd(1) and Program Library HOWTO

[dwheeler]

This is documented, and in multiple places. My Program Library HOWTO, section "Shared Libraries", says the following, and it's dated in 2000: "Beware: do not run ldd on a program you don't trust. As is clearly stated in the ldd(1) manual, ldd works by (in certain cases) by setting a special environment variable (for ELF objects, LD_TRACE_LOADED_OBJECTS) and then executing the program. It may be possible for an untrusted program to force the ldd user to run arbitrary code (instead of simply showing the ldd information). So, for safety's sake, don't use ldd on programs you don't trust to execute." Now I'd agree that it would better if ldd were changed to NOT do this. If the result of this article is a change in its code to not do this, that would be a great result. But it's simply not true that this is undocumented.