Bug 531160 - ldd Vulnerable to Social Engineering Exploits
ldd Vulnerable to Social Engineering Exploits
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: glibc (Show other bugs)
5.4
All Linux
high Severity high
: rc
: ---
Assigned To: Andreas Schwab
qe-baseos-tools
: Reopened, Security
Depends On:
Blocks: CVE-2009-5064
  Show dependency treegraph
 
Reported: 2009-10-26 22:35 EDT by Jim Dennis
Modified: 2016-11-24 11:01 EST (History)
12 users (show)

See Also:
Fixed In Version: glibc-2.5-67
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 682998 713134 (view as bug list)
Environment:
Last Closed: 2012-02-21 01:32:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
local-ldd.diff (1.35 KB, patch)
2011-02-02 09:19 EST, Tomas Hoger
no flags Details | Diff
Another suggested patch (1.50 KB, patch)
2011-03-15 10:42 EDT, Steve Grubb
no flags Details | Diff
another candidate patch (883 bytes, patch)
2011-03-15 11:35 EDT, Frank Ch. Eigler
no flags Details | Diff

  None (edit)
Description Jim Dennis 2009-10-26 22:35:49 EDT
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/
Comment 1 Ulrich Drepper 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.
Comment 2 Tomas Hoger 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?
Comment 4 Tomas Hoger 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
Comment 5 Steve Grubb 2011-03-08 08:37:28 EST
I think this bug should be re-opened. The current DISA STIG officially recommends the ldd program be disabled on our OS. Because this is now the DISA STIG recommendation, there will be a lot of calls to support about this one.

<Rule id="SV-28909r1_rule" severity="medium">
     <version>GEN007960</version>
     <title>The 'ldd' command must be disabled unless it protects against the execution of untrusted files.</title>

All it would take is adding some option like --force to preserve the old behavior and disallow untrusted linkers by default.
Comment 6 Frank Ch. Eigler 2011-03-08 14:05:34 EST
Reopening for the above reasons.
(systemtap's --ldd option uses ldd in this vulnerable capacity too.)
Comment 7 Vincent Danen 2011-03-11 19:13:07 EST
Another relevant link with some information:

http://reverse.lostrealm.com/protect/ldd.html
Comment 8 Frank Ch. Eigler 2011-03-15 10:32:00 EDT
The original behaviour of ldd was safe: it always ran ${RTLD} (ld.so) EXECUTABLE
instead.  This was changed in 1997, as per glibc git commit #2f6d1f1be

    1997-02-22 11:30  Andreas Schwab  <schwab@issan.informatik.uni-dortmund.de>
    
        * elf/ldd.bash.in: Run the program directly, not as argument
        to the dynamic linker, if it contains an interpreter segment.
        * elf/ldd.sh.in: Likewise.

IMO this should be reverted, or made non-default, or something like that, in
order to make ldd safe to run on untrusted binaries.
Comment 9 Steve Grubb 2011-03-15 10:42:44 EDT
Created attachment 485102 [details]
Another suggested patch

glibc is also an approved component for RHEL6.1. Is there a separate bug for RHEL6? Can we go ahead and fix it there so that customers do not have to delete ldd from the system per DISA STIG requirements? Preserving the old behavior while protecting against the default usage can be done with a patch like this:
Comment 10 Frank Ch. Eigler 2011-03-15 10:57:08 EDT
Steve, are you sure that patch helps?
The eu-readelf|grep is vulnerable to other mischievous data in the executable.
It does not check the putative interpreter against a list of standard ones.
It still runs "try_trace $file", which is the source of insecurity.

I agree though that the bug should be cloned for RHEL6.

My understanding is that this try_trace $file mechanism was put there so that
executables without "r" permissions could still be subjected to ldd.  (Without
read privilege on EXECUTABLE, the safer mode

    env TRACESTUFF=... /lib/ld.so.FOO EXECUTABLE

wouldn't be able to work.  It seems to me that ldd should print an error for
this case and abort, and only try the unsafe invocation with a --force option.

    env TRACESTUFF=.... EXECUTABLE
Comment 11 Tomas Hoger 2011-03-15 11:06:59 EDT
(In reply to comment #9)
> Created attachment 485102 [details]
> Another suggested patch

$ ./ldd /bin/true
Non-standard dynamic linker is requested: /lib64/ld-linux-x86-64.so.2

I guess that's not what you expect.
Comment 12 Tomas Hoger 2011-03-15 11:11:31 EDT
(In reply to comment #10)
> My understanding is that this try_trace $file mechanism was put there so that
> executables without "r" permissions could still be subjected to ldd.

Current ldd version check if file is readable and errors with 'you do not have read permission for ...' anyway.  If that was original intention for executing command directly, it does not seem valid any more.
Comment 13 Frank Ch. Eigler 2011-03-15 11:35:58 EDT
Created attachment 485521 [details]
another candidate patch

This one just takes away the 1997 option of executing the program directly.
Comment 14 Frank Ch. Eigler 2011-03-15 11:40:34 EDT
(Please excuse my reinvention of the wheel - the same proposed solution
was in the first attachment.)
Comment 15 Tomas Hoger 2011-03-17 11:35:43 EDT
(In reply to comment #12)
> (In reply to comment #10)
> > My understanding is that this try_trace $file mechanism was put there so that
> > executables without "r" permissions could still be subjected to ldd.
> 
> Current ldd version check if file is readable and errors with 'you do not have
> read permission for ...' anyway.  If that was original intention for executing
> command directly, it does not seem valid any more.

ldd version at that time did have 'test -r "$file"' test too.  It seems the reason for the change was to use whatever interpreter is noted in the file, assuming it will do the expected thing when LD_TRACE_LOADED_OBJECTS is set.
Comment 16 Tomas Hoger 2011-04-07 04:10:55 EDT
This fix was added to the fedora branch in upstream git (Andreas, thank you!):

http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=83e5edd390eabe8f8e8e0d051f929b77a30c0767

It's on in the glibc master branch yet.
Comment 18 Tomas Hoger 2011-06-14 08:57:43 EDT
The change has not made it to non-Fedora glibc master, are we going to keep this as Fedora/RHEL specific patch?
Comment 22 RHEL Product and Program Management 2011-06-27 07:39:40 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 28 errata-xmlrpc 2012-02-21 01:32:38 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0260.html

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