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."
Sounds like someone needs to make LDD not capable of executing arbitrary code then =] /captainobvious
Fetch me my tinfoil hat!
-1, Disagree is not a valid option. Troll, Flamebait and Offtopic are not a substitute.
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
'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.
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.
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
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
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.
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.
...I'm sure someone will find some other vulnerability.
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.
http://web.archive.org/web/20050211210119/http://reverse.lostrealm.com/protect/ldd.html
They should rename it iddqd in honour of this new feature.
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.
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)
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.
Right, but this trait of ldd has been around for ages. From some of the accounts around here it seems like it was actually a reasonably well-known problem. Those who wanted to exploit this issue for fun or profit have most likely been happily doing so, while those under-educated like myself who weren't aware of it could have been vulnerable to it.
With the way this thing works I'm not sure it will be fixed, at least not any time soon. "ldd" is relying upon the executable itself to report its own dependencies: when followed as a convention in a friendly environment, this is fine... In a potentially hostile environment this could be a real problem. To solve it without fundamentally changing how "ldd" works requires either education (helping people to recognize the dangers and limitations of "ldd") or else protected-environment facilities, like process jails. (If "ldd", functioning as it does, were run such that it couldn't open network connections, couldn't write to the disk, etc. then there'd be little danger of an exploit...)
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.
This boils down to relying upon "someone else" to do the work and provide me with the useful information that results from the process... The problem with that is that most other folks are also relying upon "someone else" to do this work...
Don't get me wrong, I agree with the principle of having this information out in the open. But in this case, pragmatically speaking, this appears not to have accomplished anything. How long has this problem existed? How long have people known about this? (For quite a while, it seems...) And still, there is barely even a trace of a mention of it in the manual. "Don't use this on code you don't trust" would be quite a prudent addition, I think...
Given that this issue (I hesitate to call it a "bug" - you could think of it as a bug, but it's kind of fundamental to the way ldd works... I think of it more as a fundamental miscommunication of ldd's applicability) has been around so long and hasn't been fixed, isn't mentioned in the docs, etc., I would say any complains about the Windows equivalent being closed source are rather silly in this case: the open model hasn't worked better here.
Bow-ties are cool.
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
> so I don't wind up running things that don't (like ldd) as root."
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".