Slashdot Mirror

← Back to Stories (view on slashdot.org)

Arbitrary Code Execution With "ldd"

Posted by kdawson on from the so-easy dept.

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."

16 of 184 comments (clear)

  1. the bug is not in ldd by FranTaylor · · Score: 3, Informative

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

    1. Re:the bug is not in ldd by Timothy+Brownawell · · Score: 3, 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.

    2. Re:the bug is not in ldd by marcansoft · · Score: 4, 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.

  2. Re:Another WIN in WINdows by Fizzl · · Score: 4, Informative

    http://www.dependencywalker.com/

    --
    Bot Assisted Blogging
  3. Re:Another WIN in WINdows by MyLongNickName · · Score: 4, Informative

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

    --
    See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
  4. Re:Another WIN in WINdows by joebp · · Score: 4, Informative

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

  5. And the point is... by FlyingBishop · · 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.

    1. Re:And the point is... by Anonymous Coward · · Score: 0, Informative

      So, firstly, don't run ldd as root. (I use sudo, so no issues there.)

      Dude, what are you smokin'? "sudo ldd " IS running it as root. learn2comprehend

  6. use readelf by Anonymous Coward · · Score: 1, Informative

    readelf -d

  7. Re:Specific to Linux? by __aasqbs9791 · · Score: 2, 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.

  8. Re:Specific to Linux? by theCoder · · Score: 2, 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.

    --
    "Save the whales, feed the hungry, free the mallocs" -- author unknown
  9. Wrong by Anonymous Coward · · 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.

  10. Re:Specific to Linux? by Anonymous Coward · · 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.

  11. Documented in ldd(1) and Program Library HOWTO by dwheeler · · Score: 3, Informative

    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.

    --
    - David A. Wheeler (see my Secure Programming HOWTO)
  12. Re:The problem is the executable by david_thornley · · Score: 2, Informative

    There's different ways of getting compromised executables onto systems. They're just files, after all, and lots of systems have ways of accepting arbitrary files (FTP servers, for example, often have anonymous dropboxes). The trick is to get somebody to execute them, and most people running Linux systems are a bit smarter than that. If the admins think a certain thing is harmless, and it isn't (in this case, ldd), it's an attack vector.

    --
    "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  13. Re:Thorough research by Random+Walk · · Score: 2, Informative

    The Linux manpage (on Ubuntu 8.04) says ldd prints the shared libraries required by each program or shared library specified on the command line. Note that it doesn't mention anywhere that the program is executed, and doesn't contain any security warning. If there is no hint of the problem at the primary source of usage information, then the issue IS undocumented.