Slashdot Mirror
Arbitrary Code Execution With "ldd"
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."
Uh, hello? Tech support?
You want me to do what with ldd?
Are you the same guy that told me to rm *? That wasn't funny....
---- Teach Peace. It's Cheaper Than War.
If you had read the article closely you would understand that the bug is not in ldd, it is in the dynamic loader.
In Windows, we avoid this vulnerability by giving you absolutely no fricking clue what dependencies exist for any given DLL. Suck that Unix fanboys!
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
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").
now we need to go OSS in diesel cars
'I researched this subject thoroughly and found that it's almost completely undocumented'.
Did the thorough research include a Google search for 'ldd security'?
My thorough (3 minute research) turned up this tidbit from TLDP:
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.
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
Test your net with Netalyzr
This is really nasty.
Even running the binary as nobody may get you into trouble if you are running under X because the rogue code can talk to your X server.
And of course the rogue code could print out its own prompt and fool you into thinking that you are typing at the shell. In this case you get owned when you type su and subsequently type your root password into the rogue code. You'd have to carefully inspect your running processes to not get fooled by this trick.
Maybe the answer is for ldd to use a sandbox.
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.
"I may disagree with what you say, but I will defend unto the death your right to say it." -- Voltaire
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).
now we need to go OSS in diesel cars
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!"
Trying to use sarcasm in text-based forums does not work.
I researched this subject thoroughly and found that it's almost completely undocumented.
Completely undocumented... <CARUSO NAME="david" STYLE="csi/miami" SHADES="true"> ...until now. </CARUSO>
YEAAAAAAAAAH!
Informatus Technologicus
If an ELF binary doesn't have execute permissions and you can't just set them, /lib/ld*.so will run it anyway.
Some security hacks work by making the exec syscall return an error. A sufficiently clever binary can just map ld.so and the app into itself and effectively execute anyway. Of course this won't honor setuid but it also won't remove capabilities that have been marked not permitted for the target binary.
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."
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.
http://web.archive.org/web/20050211210119/http://reverse.lostrealm.com/protect/ldd.html
They should rename it iddqd in honour of this new feature.
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)