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."
Re:ldd pwned (Score:5, Insightful)
It's the dynamic loader that knows how to interpret that executable format's list of libraries it depends on. What "ldd" does is just trigger the dynamic loader to output the libraries instead of run the program. The weakness is that an alternate dynamic loader might not do that and will just run the program anyway. Possible fixes include a new "ldd" that parses the executable itself instead of trying to get the dynamic loader to do it, or a means to restrict what dynamic loaders can be used (to just the ones that play well with "ldd").
Re:Another WIN in WINdows (Score:2, Insightful)
depends.exe. Doesn't execute arbitrary code either.
ldd is a hack and always has been. It's really just a special "run mode".
Thorough research (Score:5, Insightful)
'I researched this subject thoroughly and found that it's almost completely undocumented'.
Did the thorough research include a Google search for 'ldd security' [google.co.uk]?
My thorough (3 minute research) turned up this tidbit from TLDP [tldp.org]:
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.
User can choose to run arbitrary code... (Score:2, Insightful)
Damn,
Asking the user to install dancing_bunnies was too easy for this guy, he wants to ask the user to ldd dancing_bunnies to activate the malware.
Could as well ask the user to ACTIVATE_MALWARE=1 dancing_bunnies or LD_PRELOAD=dancing_bunnies.so your_app for letting the user running the malware from any your_app he likes.
Cool and so what (Score:4, Insightful)
On one hand that is a cool little hack. But on the other hand, so what? How many cases occur where even with social engineering will someone run ldd but not run the executable? E.g. In the example most sysadmins would run the program itself anyway
Specific to Linux? (Score:5, Insightful)
It'd be nice if the author made it more clear what OS this is claimed to apply to. For example, Solaris 10 has /usr/bin/ldd as an ELF. I don't have my HP-UX or AIX test systems handy, nevermind recent releases of RHEL.
Also, what efforts has the coder gone to in order to notify the appropriate security groups so that a fix can be produced quickly? I'm not disputing the potential security issues, but there is a reason for first disclosing to a vendor on non-public channels. Give the vendor/coder the chance to do the right thing and produce a fix.
The bug is not in the dynamic loader (Score:5, Insightful)
Actually, no. The bug is NOT in the dynamic loader. In particular, when the exploiting executable specifies a different dynamic loader in the binary interpreter field, then the system dynamic loader is not even involved.
RTFA again. The exploit involves using a different dynamic loader. The evil person has made a fake loader that does the evil deed. That's NOT a bug, since it does what he (the evil person) wanted.
The bug is ... at least partly ... in the /usr/bin/ldd script. The real source of the bug is in the thinking that every dynamic loader would do this and that no dynamic loader that failed to would ever be used. That's saying that the design of doing it this way is what is buggy.
There are some possible fixes. One fix is to make a program to replace /usr/bin/ldd that understand by itself how to parse and interpret all executables. That might be done best via a new flag on the dynamic linker or dynamic loader programs. This needs to work for all executable formats the system might need to work with. Another fix is to provide for a list of allowed (trusted) dynamic loaders that would be enforced most likely by the kernel. That list could be managed via a /proc entry that can only be written/appended to by root (and uses a built-in list prepared when the kernel was compiled, whenever that /proc entry list is empty).
New Lingo (Score:5, Insightful)
I researched this subject thoroughly and found that it's almost completely undocumented.'
Is this the new way to say "I checked it out and it's legit!"
Re:Cool and so what (Score:4, Insightful)
times like this, I just want to be able to say:
sandbox $whatever_command
and have it run in a completely safe environment.
We have usermode linux, how hard would it be to have such a thing self-contained and operating in a read-from-real-filesystem,write-to-virtual-filesystem,--disable-all,--enable-fake-internet, manner?
Or does such a thing exist? Security for examining someone else's arbitrary commands doesn't seem like it should be an unsolved problem
Re:the bug is not in ldd (Score:5, Insightful)
How many programs on your system do you *fully* understand? How certain are you about that? [bell-labs.com]
Re:Another WIN in WINdows (Score:3, Insightful)
Re:And the point is... (Score:3, Insightful)
I think (hope) that he meant, "I use sudo for things that need root, so I don't wind up running things that don't (like ldd) as root."
Re:User can choose to run arbitrary code... (Score:4, Insightful)
It's not quite the same thing. Since the binary you're looking at has to have this exploit in it, your example might as well just run `dancing_bunnies` in the first place. The reason this is an issue is because it will run while doing `ldd dancing_bunnies` where you would expect ldd not to run any arbitrary code.
1985 called, they want their exploit back (Score:5, Insightful)
http://web.archive.org/web/20050211210119/http://reverse.lostrealm.com/protect/ldd.html [archive.org]
Re:Specific to Linux? (Score:3, Insightful)
As I understand it, it's not really a bug but a security issue that many are unaware of. It's similar to how many email worms send out .scr files (screensaver) because many people know not to run unknown .exe files.
Re:Another WIN in WINdows (Score:1, Insightful)
It only takes one.
And the odds of one out of millions will be the one is quite high (Unless only one person uses the app)
However one is still heads and shoulders higher than the number of users of the windows app, even if there are more than a million using it.
Re:Another WIN in WINdows (Score:5, Insightful)
Also note that Dependency Walker itself might as well be arbitrary code since I can't read its source code.
I've had the full source code for "ldd" on my linux box for the past thirteen years... What good has that done in this case?
Re:Thorough research (Score:3, Insightful)
So what? (Score:3, Insightful)
In other news, "nice" is considered dangerous because when you run nice with the command line parameter of a program, it executes the program! And crond. And at. And sudo. And bash. And a million script files.
This isn't shocking, it's stupid. Possibly slightly unexpected if you're a new admin, that's about it.
Re:Another WIN in WINdows (Score:4, Insightful)
I've had the full source code for "ldd" on my linux box for the past thirteen years... What good has that done in this case?
The good that it has done is that the author of this article DID have access to the source, analyzed it, found a vulnerability and now you, me or anyone else can (and no doubt will) patch it. The point of the source being available isn't that you personally need to look through every line of code that your system executes, but rather that it is made available to anyone to analyze for security, efficiency, correctness, etc. instead of being locked up in a vault somewhere.
Not running as root doesn't mean it's safe (Score:3, Insightful)
But how does that help "Mr/Ms Desktop User"?
Most of Desktop User's "crown jewels" would be in the home directory, and even if it's not it would be fully accessible by the arbitrary code and subsequently installed malware since it would be running using "Desktop User"'s account.
The arbitrary code executed does not need root to turn the machine into a zombie and then execute other code, send spam, DDoS stuff, etc.
This fixation on "not getting root means I'm safe" is WRONG!
As long as we are using the current primitive privilege systems, it's not safe. Windows does allow some sandboxing, but there's a lot of room for improvement. Desktop Linux? There's SELinux and AppArmor, you're welcome to figure out how to make either/both "desktop ready".