Bug 682998

Cloning for Rawhide.  While folks may disagree on the implications of the flaw, a non-intrusive fix for this exists, which does not seem to have negative side effects.  The patch is in use by couple of distributions for some time.


+++ This bug was initially created as a clone of Bug #531160 +++

The ldd attempts to display a list of dynamic linkages by executing the target binary with an "magic environment" setting.  For a normal binary that's been compiled and linked with glibc and the normal GNU linker this will be adequate.

However, crafted sources linked against an alternative library and linker can execute arbitrary code in lieu (or in addition to) this.

Because most sysadmins are not aware of this behavior they will have the (reasonable) expectation that ldd is inspecting the target's headers (as data) rather than EXECUTING them.  This makes ldd an ideal mechanism for social engineering exploits by users against sysadmins or site developers.

Detailed explanation and sample code has been found on:

http://www.catonmat.net/blog/ldd-arbitrary-code-execution/

--- Additional comment from drepper.fsp@... on 2009-11-24 21:57:52 EST ---

This is just nonsense.  There are a gazillion other ways to introduce code if people are downloading arbitrary binaries and install them in appropriate directories or set LD_LIBRARY_PATH etc.  Just don't do that.

--- Additional comment from thoger@... on 2011-02-02 09:19:20 EST ---

Created attachment 476574 [details]
local-ldd.diff

ldd patch from the Debian eglibc packages.  It avoids this issue by ensuring that ldd always does:

  LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 /path/to/ELF-lib-or-binary

rather than:

  LD_TRACE_LOADED_OBJECTS=1 /path/to/ELF-lib-or-binary

This change is not part of upstream glibc.  I don't seem to be able to find any reference to this change on sourceware.org, so I'm not sure if it was ever proposed upstream.  Does it this change break any expected use to explain why this fix should not make it upstream?

--- Additional comment from thoger@... on 2011-03-08 04:06:24 EST ---

(In reply to comment #2)
> ldd patch from the Debian eglibc packages.  It avoids this issue by ensuring
> that ldd always does:
> 
>   LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 /path/to/ELF-lib-or-binary
> 
> rather than:
> 
>   LD_TRACE_LOADED_OBJECTS=1 /path/to/ELF-lib-or-binary

Apparently, Owl / ALT Linux is using the similar approach for a quite some time too:

http://thread.gmane.org/gmane.comp.security.oss.general/4427/focus=4428
http://cvsweb.openwall.com/cgi/cvsweb.cgi/~checkout~/Owl/packages/glibc/glibc-2.3.6-owl-alt-ldd.diff
http://git.altlinux.org/gears/g/glibc.git?p=glibc.git;a=commitdiff;h=788577027d2950e9508a434475e04c3af864d169