Arbitrary Code Execution With "ldd" 184
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."
the bug is not in ldd (Score:4, Informative)
If you had read the article closely you would understand that the bug is not in ldd, it is in the dynamic loader.
Re:Another WIN in WINdows (Score:5, Informative)
http://www.dependencywalker.com/ [dependencywalker.com]
Re:Another WIN in WINdows (Score:5, Informative)
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 (Score:5, Informative)
And the point is... (Score:2, Informative)
So, firstly, don't run ldd as root. (I use sudo, so no issues there.)
Secondly, don't use ldd on untrusted binaries. If you don't trust it why are you trying to run it? I suppose this is useful to see if the attacker is being really obvious and dynamically linking to net-code in a program that shouldn't need net, but other than that I don't see where this is going to be a serious problem, except in the case where you have a direct line to your sysadmin, but if that's the case there are probably a dozen different ways you can trick him into running arbitrary code, not the least of which is "hey, can you install this for me? I need it to get x done." If you're intelligent enough to hack a binary, I think you're intelligent enough that you can come up with a plausible reason your admin should install something you compiled yourself.
Re:the bug is not in ldd (Score:4, Informative)
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:And the point is... (Score:0, Informative)
Dude, what are you smokin'? "sudo ldd " IS running it as root. learn2comprehend
use readelf (Score:1, Informative)
readelf -d
Re:Specific to Linux? (Score:3, Informative)
From what I can tell, you can't really fix this as it is what the program does (though I could be wrong). It runs the program to find out what libraries it requires. That's why there's a warning that tells you not to run this on an untrusted program (linked to in a post above). It's sort of like saying sudo is a vulnerability because it lets you run untrusted program code.
Re:Specific to Linux? (Score:3, Informative)
The author mentioned that on BSD the `ldd' app is a C app that does basically what the Linux shell script `ldd' does. The Solaris `ldd' is also an app, so I can't verify that it's the same as on BSD, but setting LD_TRACE_LOADED_OBJECTS=1 before running an application does cause ldd like output, so I would suspect the same rules apply under Solaris as described in the article.
Wrong (Score:1, Informative)
Actually, that is wrong. Dependency Walker can, if you order it to, execute arbitrary code. It has to, because otherwise you could never have the profiling feature that enables you to hunt for hidden run-time dependencies.
Re:Specific to Linux? (Score:2, Informative)
on NetBSD 4.0_STABLE:
> LD_TRACE_LOADED_OBJECTS=1 ls
shows normal ls output
> file `which ldd` /usr/bin/ldd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for NetBSD 4.0, dynamically linked (uses shared libs), not stripped
I've looked through the NetBSD ldd source and it does seem to parse the elf imports table etc rather then running the program.
Re:the bug is not in ldd (Score:5, Informative)
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.
Documented in ldd(1) and Program Library HOWTO (Score:4, Informative)
Re:The problem is the executable (Score:3, Informative)
Re:Thorough research (Score:3, Informative)