Bug 682998 - glibc: improve ldd safety
Summary: glibc: improve ldd safety
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Andreas Schwab
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-08 09:22 UTC by Tomas Hoger
Modified: 2016-11-24 15:54 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 531160
Environment:
Last Closed: 2011-07-26 11:56:48 UTC


Attachments (Terms of Use)

Description Tomas Hoger 2011-03-08 09:22:02 UTC
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


Note You need to log in before you can comment on or make changes to this bug.