Arbitrary code execution via ldd utility | Hacker News Reader

Arbitrary code execution via ldd utility

catonmat.net

83 pointspkrumins18 comments

This is only a vulnerability if you don't know what ldd does. The problem is that it's not necessarily easy to find out what ldd does.

The man pages for Solaris 8-10 will tell you not to run it on untrusted files. But, if you Google "man ldd" you may get this page (the first result for me, btw):

http://unixhelp.ed.ac.uk/CGI/man-cgi?ldd+1

Which is very sparse. If you are not an experienced SA you may not notice that the information is old, or not applicable to your platform. There are a lot of quasi-administrators (techy folk in your dept. w/ admin privileges) who may be vulnerable to social engineering by a consultant or evil employee (I've seen both happen).

We are all vulnerable to what we don't know.

That link is actually the current one on my Debian testing/Squeeze system. Its part of at least reasonably current glibc releases.

I don't consider this "arbitrary code execution." To me, that implies that someone not logged into the system was able to exploit a vulnerability in an externally facing application.

In this case, the author assumes a login. That's like explaining how to break into someone's house and starting with "Okay, you're on the other side of someone's door. Now you can do what you want!" It just turns out that the semantics of ldd are to run the program. This is no more arbitrary code execution than tricking someone on Windows to run your program by saying "Download this file and double-click it."

Exactly my thought.

The arbitrary code is executed only when the user tells to do so. This is not a bug, it is a feature. Computers are supposed to work like that.

Raymond Chen observes: (link: http://blogs.msdn.com/oldnewthing/archive/2008/05/16/8510192...)

It is not a security vulnerability that users with permission to shut down the computer can shut down the computer. This is another example of people getting excited that they were able to do something unusual. But just because you can do something unusual doesn’t mean that you’ve found a security vulnerability.

I thought of Raymond Chen, too! I Googled until I found the entry you found, but also this one (http://blogs.msdn.com/oldnewthing/archive/2006/05/08/592350....), which has the observation:

Code injection doesn't become a security hole until you have elevation of privilege.

Chen's the one who originally made me realize the distinction between tricking someone into running a program, and an actual security vulnerability.

The main difference between saying "Download this file and double-click it" and saying "run ldd on this file" is that it is surprising to at least the author (and me) that ldd does in fact execute code in that file.

Yeah, I'm real glad that the Unix permission scheme is actually worthless because of non user intended code execution in core utilities.

I'm not sure that snark is warranted. This is a development tool. You use ldd when you're curious what libraries a binary links against; more or less by definition that's because you're planning to run said binary at some point in the future.

The only path to a security vulnerability here is to fool the user into linking against untrusted binaries and libraries. But that's protected by the default link paths already. So you'd first have to fool them into setting their LD_LIBRARY_PATH properly, and then get the bad binary on the system.

So how is this easier than just fooling them into opening a shell for you?

> The only path to a security vulnerability here is to fool the user into linking against untrusted binaries and libraries.

Not quite. You fool someone into checking what libraries is your file linked against, which most people would assume - is a safe operation (just reading some info, right?) It doesn't need any lookup path modification, because rpath can be compiled into the binary itself. Basically you can prepare anything you need in your home directory. The only part that someone else has to do is to run `ldd your_file`.

It's not only a development tool. It's also a sysadmin and packaging tool. Some parts of .deb and .rpm automation depend on that ldd (you don't have to use that, but it's nice when the dependencies are found automatically)

I think we agree on the facts, just not the interpretation. Once more, it requires getting an untrusted binary into the target user's environment such that they can be fooled into running it.

How is that different from any of the four million other ways of fooling users into running untrusted binaries?

Clearly the difference is in the subtly. The arbitrary code being run is in the loader, not the body of the executable, allowing it to be run without an explicit, "go to the shell and run my binary," step. This will be a new attack vector to many people.

Does anyone know why does `ldd` use the loader? Only to resolve the names? It seems that you can get the basic names from objdump too (dynamic section / `NEEDED` symbols)

It seems that it's easy to "secure" this bug... if you have more caps than the owner of the loader, warn that you need a special flag and exit. Selinux and similar might make that decision harder though...

My guess is just not wanting to duplicate functionality. The loader needs to figure out what libraries to load at runtime, and it's easier and more reliable to just ask the loader than to write code that does the same thing.

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. When I run it, I get an error saying something about the permissions on /usr/share/zoneinfo-something. Can you help me?”

Sysadmin: “Sure. What app is it?”

You: “It’s in my home directory, /home/carl/app/bin/myapp."

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

Sysadmin: “I didn't see any error.”

You: “Nevermind, I figured it out. Thanks!.”

Narrator: Did you notice what went wrong in this scene? The administrator was supposed to check the permissions on all the files in /usr/share, thus earning the slim chance to perform the reproductive act. The next day, the administrator's planet was destroyed by aliens. Can you guess the name of the planet? IT WAS EARTH! DON'T DATE ROBOTS."

I've been a sysadmin for several years now.

I don't know what would possess me to run that program as me, I would run it as them. That's if I ran it at all since I would check the fault they reported first anyway.

Uh-huh. But you'd ldd it as you?

Yes I see your point better now. I'd probably would have ldd'ed it till I found out how it worked from the article, now I won't anymore.

However given that I would know exactly who the user was - any damage that was intentional by them would have consequences for them.

It seems that there may be a use for an ldd-like utility that doesn't actually load the binary, for use by security researchers. Now that I know it makes perfect sense, but intuitively I would have expected ldd to just read the data from the binary directly instead of relying on the system loader.

Reply on news.ycombinator.com