Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Steven Honeyman]

I noticed this by accident (ran ldd as usual without even thinking)...
but if you compile with musl-gcc, and use shared instead of static,
then ldd can cause different behaviour in the binary (code will
execute). It is described here [1] from 2009, on how to modify uclibc
to enable this behaviour... musl needs no mods to achieve this!

Simple example:

$ echo 'void main() { puts("executed"); }' >lddtest.c
$ musl-gcc lddtest.c && ldd ./a.out

Of course the exploit is only useable if you check for
LD_TRACE_LOADED_OBJECTS and do something different in the code if it
is set.

Thanks,
Steven.

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

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Szabolcs Nagy]

* Steven Honeyman <stevenhoneyman@gmail.com> [2014-06-14 16:35:25 +0100]:
> I noticed this by accident (ran ldd as usual without even thinking)...
> but if you compile with musl-gcc, and use shared instead of static,
> then ldd can cause different behaviour in the binary (code will
> execute). It is described here [1] from 2009, on how to modify uclibc
> to enable this behaviour... musl needs no mods to achieve this!

musl never had this problem by design

it's only the broken ldd of glibc that tries to execute the binary..

> $ echo 'void main() { puts("executed"); }' >lddtest.c
> $ musl-gcc lddtest.c && ldd ./a.out
> 
> Of course the exploit is only useable if you check for
> LD_TRACE_LOADED_OBJECTS and do something different in the code if it
> is set.

works here as expected

the environment variables the libc and loader cares about are
documented: http://www.musl-libc.org/doc/1.0.0/manual.html
(LD_TRACE_LOADED_OBJECTS is not listed there)

$ ldd
musl libc
Version 1.1.2-git-7-g66fcde4
Dynamic Program Loader
Usage: ldd [options] [--] pathname

$ ldd ./a.out 
        /lib/ld-musl-i386.so.1 (0xb76cd000)
        libc.so => /lib/ld-musl-i386.so.1 (0xb76cd000)

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Daniel Cegiełka]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

musl checks suid/sgid

http://git.musl-libc.org/cgit/musl/tree/src/ldso/dynlink.c#n984

Daniel



2014-06-14 17:35 GMT+02:00 Steven Honeyman <stevenhoneyman@gmail.com>:

> I noticed this by accident (ran ldd as usual without even thinking)...
> but if you compile with musl-gcc, and use shared instead of static,
> then ldd can cause different behaviour in the binary (code will
> execute). It is described here [1] from 2009, on how to modify uclibc
> to enable this behaviour... musl needs no mods to achieve this!
>
> Simple example:
>
> $ echo 'void main() { puts("executed"); }' >lddtest.c
> $ musl-gcc lddtest.c && ldd ./a.out
>
> Of course the exploit is only useable if you check for
> LD_TRACE_LOADED_OBJECTS and do something different in the code if it
> is set.
>
> Thanks,
> Steven.
>
> [1] http://www.catonmat.net/blog/ldd-arbitrary-code-execution/
>

[-- Attachment #2: Type: text/html, Size: 1436 bytes --]

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Szabolcs Nagy]

* Daniel Cegie??ka <daniel.cegielka@gmail.com> [2014-06-14 17:51:43 +0200]:
> musl checks suid/sgid
> 
> http://git.musl-libc.org/cgit/musl/tree/src/ldso/dynlink.c#n984
> 

http://git.musl-libc.org/cgit/musl/tree/src/ldso/dynlink.c#n1201

this is the relevant line: musl's loader exits before
executing main in ldd mode independently of setuid or
env vars the checked binary has no control over this
at all

in glibc the interpreter linked into the binary has to
do the right thing.. and it used to fail to do that
(and of course if you have a binary with non-glibc
interpreter it does the wrong thing with arbitrarily
bad consequences..)

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Rich Felker]

On Sat, Jun 14, 2014 at 06:03:02PM +0200, Szabolcs Nagy wrote:
> * Daniel Cegie??ka <daniel.cegielka@gmail.com> [2014-06-14 17:51:43 +0200]:
> > musl checks suid/sgid
> > 
> > http://git.musl-libc.org/cgit/musl/tree/src/ldso/dynlink.c#n984
> > 
> 
> http://git.musl-libc.org/cgit/musl/tree/src/ldso/dynlink.c#n1201
> 
> this is the relevant line: musl's loader exits before
> executing main in ldd mode independently of setuid or
> env vars the checked binary has no control over this
> at all

Steven Honeyman's original report was in regard to using the glibc ldd
utility with musl binaries. This just executes the program normally,
but it does not give you any elevated privileges you wouldn't already
have by executing it directly.

Rich

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Rich Felker]

On Sat, Jun 14, 2014 at 04:35:25PM +0100, Steven Honeyman wrote:
> I noticed this by accident (ran ldd as usual without even thinking)...
> but if you compile with musl-gcc, and use shared instead of static,
> then ldd can cause different behaviour in the binary (code will
> execute). It is described here [1] from 2009, on how to modify uclibc
> to enable this behaviour... musl needs no mods to achieve this!
> 
> Simple example:
> 
> $ echo 'void main() { puts("executed"); }' >lddtest.c
> $ musl-gcc lddtest.c && ldd ./a.out
> 
> Of course the exploit is only useable if you check for
> LD_TRACE_LOADED_OBJECTS and do something different in the code if it
> is set.

I fail to see how this is exploiting anything. Running a musl-based
program with the glibc ldd utility does the exact same thing as
running the musl-based program directly. This does not give you any
additional privileges.

> [1] http://www.catonmat.net/blog/ldd-arbitrary-code-execution/

This is a social engineering exploit against the administrator. The
whole reason it happened is because somebody (not sure who was
originally responsible for this mistake) designed their ldd to
actually run the program, which is a horrible design. musl's ldd does
not do this, and musl does not support LD_TRACE_LOADED_OBJECTS. Yes
this makes it easier to make binaries that can be used for social
engineering, but it does not expose users of musl to any additional
danger, and in my view it actually increases awareness about the
danger of glibc ldd since users who run it on musl binaries see
immediately what it's doing behind the curtains. (Actually, I think
this issue may be fixed in modern glibc ldd, but I'm not sure.)

Rich

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Steven Honeyman]

I'm not suggesting it is the "fault" of musl - but as in your own
words, it provides a social engineering exploit.

ldd (GNU libc) 2.19
Copyright (C) 2014

^ still works with that version. As for "additional danger" - sure it
can: if (getenv("LD_TRACE_LOADED_OBJECTS")) eraseHomeDir();

I was suggesting/posting this thinking it be a good idea to check for
LD_TRACE_LOADED_OBJECTS and output something e.g. "Please use ldd from
musl" then exit?
Even without root permissions, a careless user could still have their
files wiped out (etc).


Thanks,
Steven

On 14 June 2014 17:02, Rich Felker <dalias@libc.org> wrote:
> On Sat, Jun 14, 2014 at 04:35:25PM +0100, Steven Honeyman wrote:
>> I noticed this by accident (ran ldd as usual without even thinking)...
>> but if you compile with musl-gcc, and use shared instead of static,
>> then ldd can cause different behaviour in the binary (code will
>> execute). It is described here [1] from 2009, on how to modify uclibc
>> to enable this behaviour... musl needs no mods to achieve this!
>>
>> Simple example:
>>
>> $ echo 'void main() { puts("executed"); }' >lddtest.c
>> $ musl-gcc lddtest.c && ldd ./a.out
>>
>> Of course the exploit is only useable if you check for
>> LD_TRACE_LOADED_OBJECTS and do something different in the code if it
>> is set.
>
> I fail to see how this is exploiting anything. Running a musl-based
> program with the glibc ldd utility does the exact same thing as
> running the musl-based program directly. This does not give you any
> additional privileges.
>
>> [1] http://www.catonmat.net/blog/ldd-arbitrary-code-execution/
>
> This is a social engineering exploit against the administrator. The
> whole reason it happened is because somebody (not sure who was
> originally responsible for this mistake) designed their ldd to
> actually run the program, which is a horrible design. musl's ldd does
> not do this, and musl does not support LD_TRACE_LOADED_OBJECTS. Yes
> this makes it easier to make binaries that can be used for social
> engineering, but it does not expose users of musl to any additional
> danger, and in my view it actually increases awareness about the
> danger of glibc ldd since users who run it on musl binaries see
> immediately what it's doing behind the curtains. (Actually, I think
> this issue may be fixed in modern glibc ldd, but I'm not sure.)
>
> Rich

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Rich Felker]

On Sat, Jun 14, 2014 at 05:10:40PM +0100, Steven Honeyman wrote:
> I'm not suggesting it is the "fault" of musl - but as in your own
> words, it provides a social engineering exploit.
> 
> ldd (GNU libc) 2.19
> Copyright (C) 2014
> 
> ^ still works with that version. As for "additional danger" - sure it
> can: if (getenv("LD_TRACE_LOADED_OBJECTS")) eraseHomeDir();
> 
> I was suggesting/posting this thinking it be a good idea to check for
> LD_TRACE_LOADED_OBJECTS and output something e.g. "Please use ldd from
> musl" then exit?
> Even without root permissions, a careless user could still have their
> files wiped out (etc).

It's inherently unsafe to run glibc ldd on binaries you don't trust:
it's equivalent to running the binary and giving it full access to the
invoker's privileges. For musl to suppress this as you suggested does
not protect anyone. An attacker making a malicious binary can just
modify musl (or just make a static-linked binary) for use in the
attack. All that processing LD_TRACE_LOADED_OBJECTS would do is
prevent non-malicious binaries from running when it's set, which
itself could be a source of exploits (e.g. arranging for a script not
to execute a command it should by having LD_TRACE_LOADED_OBJECTS in
the environment when the command is run; this could work especially
well on systems with a mix of static and dynamic binaries where only
the dynamic binaries would be suppressed).

Rich

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Solar Designer]

Rich,

On Sat, Jun 14, 2014 at 12:02:43PM -0400, Rich Felker wrote:
> (Actually, I think
> this issue may be fixed in modern glibc ldd, but I'm not sure.)

IIRC, we have this worked around in patched glibc's ldd on Owl by having
it always explicitly run the program through /lib/ld-linux.so.2, which
obviously does interpret its env vars that the ldd script sets.  That ldd
script assumes glibc's /lib/ld-linux.so.2 anyway (env vars, exit codes).

I don't know why upstream glibc would not(?) patch the issue that way.
It's a trivial change.  Is there some WONTFIX for this in glibc Bugzilla
already?  Sounds like material for your blog if so. ;-)

Alexander

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Rich Felker]

On Sat, Jun 14, 2014 at 08:14:01PM +0400, Solar Designer wrote:
> Rich,
> 
> On Sat, Jun 14, 2014 at 12:02:43PM -0400, Rich Felker wrote:
> > (Actually, I think
> > this issue may be fixed in modern glibc ldd, but I'm not sure.)
> 
> IIRC, we have this worked around in patched glibc's ldd on Owl by having
> it always explicitly run the program through /lib/ld-linux.so.2, which
> obviously does interpret its env vars that the ldd script sets.  That ldd
> script assumes glibc's /lib/ld-linux.so.2 anyway (env vars, exit codes).

One improvement to this, if one wants to support multiple glibc
installations with different interpreters, would be parsing the
PT_INTERP from the binary, then exec'ing it in a way that inhibits
suid if the pointed-to binary happens to be suid. (One idea is
open+fstat+fexecve; another is ptrace+exec, where ptrace just serves
to inhibit suid.)

> I don't know why upstream glibc would not(?) patch the issue that way.
> It's a trivial change.  Is there some WONTFIX for this in glibc Bugzilla
> already?  Sounds like material for your blog if so. ;-)

There was a new patch for this issue on the libc-alpha list back in
March of this year, but I don't think it's been committed yet. See
"[PATCH] Never try to execute the file in ldd", Message-ID:
<mvma9cfobqi.fsf@hawking.suse.de>.

Rich

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Steven Honeyman]

A quick search suggests it's been "patched" in Debian, Redhat, Owl
glibc packages at least, but not upstream yet for some reason.


If that libc-alpha commit makes it through (eventually!) then agreed,
this is no longer an issue.


On 14 June 2014 17:24, Rich Felker <dalias@libc.org> wrote:
> On Sat, Jun 14, 2014 at 08:14:01PM +0400, Solar Designer wrote:
>> Rich,
>>
>> On Sat, Jun 14, 2014 at 12:02:43PM -0400, Rich Felker wrote:
>> > (Actually, I think
>> > this issue may be fixed in modern glibc ldd, but I'm not sure.)
>>
>> IIRC, we have this worked around in patched glibc's ldd on Owl by having
>> it always explicitly run the program through /lib/ld-linux.so.2, which
>> obviously does interpret its env vars that the ldd script sets.  That ldd
>> script assumes glibc's /lib/ld-linux.so.2 anyway (env vars, exit codes).
>
> One improvement to this, if one wants to support multiple glibc
> installations with different interpreters, would be parsing the
> PT_INTERP from the binary, then exec'ing it in a way that inhibits
> suid if the pointed-to binary happens to be suid. (One idea is
> open+fstat+fexecve; another is ptrace+exec, where ptrace just serves
> to inhibit suid.)
>
>> I don't know why upstream glibc would not(?) patch the issue that way.
>> It's a trivial change.  Is there some WONTFIX for this in glibc Bugzilla
>> already?  Sounds like material for your blog if so. ;-)
>
> There was a new patch for this issue on the libc-alpha list back in
> March of this year, but I don't think it's been committed yet. See
> "[PATCH] Never try to execute the file in ldd", Message-ID:
> <mvma9cfobqi.fsf@hawking.suse.de>.
>
> Rich

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Szabolcs Nagy]

* Steven Honeyman <stevenhoneyman@gmail.com> [2014-06-14 17:27:33 +0100]:
> 
> If that libc-alpha commit makes it through (eventually!) then agreed,
> this is no longer an issue.
> 

i dont see how this is an issue

it is simply not the responsibility of musl to fix or
work around such bugs in other projects even if it were
dangerous

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Rich Felker]

On Sat, Jun 14, 2014 at 06:42:56PM +0200, Szabolcs Nagy wrote:
> * Steven Honeyman <stevenhoneyman@gmail.com> [2014-06-14 17:27:33 +0100]:
> > 
> > If that libc-alpha commit makes it through (eventually!) then agreed,
> > this is no longer an issue.
> > 
> 
> i dont see how this is an issue
> 
> it is simply not the responsibility of musl to fix or
> work around such bugs in other projects even if it were
> dangerous

Indeed, I see the request to "fix" this on musl's side as a request
for something that falls midway between security-through-obscurity and
DRM. It's not musl's responsibility to make it difficult to write
malicious programs any more than it's the compiler's responsibility to
do so, and of couse since musl is open source, it's not even possible
to actually prevent users from doing so.

Rich

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Solar Designer]

On Sat, Jun 14, 2014 at 12:24:43PM -0400, Rich Felker wrote:
> On Sat, Jun 14, 2014 at 08:14:01PM +0400, Solar Designer wrote:
> > On Sat, Jun 14, 2014 at 12:02:43PM -0400, Rich Felker wrote:
> > > (Actually, I think
> > > this issue may be fixed in modern glibc ldd, but I'm not sure.)
> > 
> > IIRC, we have this worked around in patched glibc's ldd on Owl by having
> > it always explicitly run the program through /lib/ld-linux.so.2, which
> > obviously does interpret its env vars that the ldd script sets.  That ldd
> > script assumes glibc's /lib/ld-linux.so.2 anyway (env vars, exit codes).
> 
> One improvement to this, if one wants to support multiple glibc
> installations with different interpreters, would be parsing the
> PT_INTERP from the binary, then exec'ing it in a way that inhibits
> suid if the pointed-to binary happens to be suid. (One idea is
> open+fstat+fexecve; another is ptrace+exec, where ptrace just serves
> to inhibit suid.)

I don't understand what scenario you have in mind.  When we invoke the
interpreter explicit, we already inhibit a possible SUID/SGID on the
target binary.

> > I don't know why upstream glibc would not(?) patch the issue that way.
> > It's a trivial change.  Is there some WONTFIX for this in glibc Bugzilla
> > already?  Sounds like material for your blog if so. ;-)
> 
> There was a new patch for this issue on the libc-alpha list back in
> March of this year, but I don't think it's been committed yet. See
> "[PATCH] Never try to execute the file in ldd", Message-ID:
> <mvma9cfobqi.fsf@hawking.suse.de>.

Yes, it's the same patch we've been using for years.

https://sourceware.org/ml/libc-alpha/2014-03/msg00713.html

BTW, it wasn't the social engineering attack possibility that provided
the initial motivation for us to patch the issue:

* Wed Jun 12 2002 Solar Designer <solar-at-owl.openwall.com>
- ldd(1) will no longer try to invoke programs directly, even when it
seems like that would work.  The dynamic linker will be invoked as a
program instead.  This makes a difference when the program is SGID and
is being ldd'ed by root.  If the program was executed directly, glibc
would detect its SGID status and drop LD_* variables, resulting in the
program being actually started rather than ldd'ed.  Thanks to Dmitry
V. Levin of ALT Linux for suggesting this solution.

Maybe stock glibc doesn't ignore LD_TRACE_LOADED_OBJECTS for SGID (nor
for SUID?), which is why it didn't(?) have that other issue exposed.

I notice that Dmitry has already commented in that recent libc-alpha
thread as well.

Alexander

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Rich Felker]

On Sat, Jun 14, 2014 at 09:24:11PM +0400, Solar Designer wrote:
> On Sat, Jun 14, 2014 at 12:24:43PM -0400, Rich Felker wrote:
> > On Sat, Jun 14, 2014 at 08:14:01PM +0400, Solar Designer wrote:
> > > On Sat, Jun 14, 2014 at 12:02:43PM -0400, Rich Felker wrote:
> > > > (Actually, I think
> > > > this issue may be fixed in modern glibc ldd, but I'm not sure.)
> > > 
> > > IIRC, we have this worked around in patched glibc's ldd on Owl by having
> > > it always explicitly run the program through /lib/ld-linux.so.2, which
> > > obviously does interpret its env vars that the ldd script sets.  That ldd
> > > script assumes glibc's /lib/ld-linux.so.2 anyway (env vars, exit codes).
> > 
> > One improvement to this, if one wants to support multiple glibc
> > installations with different interpreters, would be parsing the
> > PT_INTERP from the binary, then exec'ing it in a way that inhibits
> > suid if the pointed-to binary happens to be suid. (One idea is
> > open+fstat+fexecve; another is ptrace+exec, where ptrace just serves
> > to inhibit suid.)
> 
> I don't understand what scenario you have in mind.  When we invoke the
> interpreter explicit, we already inhibit a possible SUID/SGID on the
> target binary.

I was thinking of scenarios where the interpreter is suid, but that's
probably actually not what we need to be worried about. The attack is
where the interpreter is provided by the user who asked you to invoke
ldd. There are some sanity checks that could still be done with the
open+fstat+fexecve approach, but I don't think they can be made
sufficiently complete so the best approach is probably just printing
an error (and giving the user an option to --force) if PT_INTERP does
not match what ldd expects it to be.

> BTW, it wasn't the social engineering attack possibility that provided
> the initial motivation for us to patch the issue:
> 
> * Wed Jun 12 2002 Solar Designer <solar-at-owl.openwall.com>
> - ldd(1) will no longer try to invoke programs directly, even when it
> seems like that would work.  The dynamic linker will be invoked as a
> program instead.  This makes a difference when the program is SGID and
> is being ldd'ed by root.  If the program was executed directly, glibc
> would detect its SGID status and drop LD_* variables, resulting in the
> program being actually started rather than ldd'ed.  Thanks to Dmitry
> V. Levin of ALT Linux for suggesting this solution.
> 
> Maybe stock glibc doesn't ignore LD_TRACE_LOADED_OBJECTS for SGID (nor
> for SUID?), which is why it didn't(?) have that other issue exposed.

Stock glibc accepts all of the LD_* environment variables for
suid/sgid, including dangerous ones, and only applies weak
restrictions to them (for example it even allows LD_PRELOAD after
imposing some insufficient conditions on the library to be preloaded).

> I notice that Dmitry has already commented in that recent libc-alpha
> thread as well.

Ah yes. :)

Rich

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Solar Designer]

On Sat, Jun 14, 2014 at 02:29:42PM -0400, Rich Felker wrote:
> Stock glibc accepts all of the LD_* environment variables for
> suid/sgid, including dangerous ones, and only applies weak
> restrictions to them (for example it even allows LD_PRELOAD after
> imposing some insufficient conditions on the library to be preloaded).

Oh, I recall it allows LD_PRELOAD on libraries that are placed in system
directories and are themselves marked with the SUID bit.  IIRC, libc5's
dynamic linker had that, too.

Alexander

Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit

[Rich Felker]

On Sat, Jun 14, 2014 at 10:37:25PM +0400, Solar Designer wrote:
> On Sat, Jun 14, 2014 at 02:29:42PM -0400, Rich Felker wrote:
> > Stock glibc accepts all of the LD_* environment variables for
> > suid/sgid, including dangerous ones, and only applies weak
> > restrictions to them (for example it even allows LD_PRELOAD after
> > imposing some insufficient conditions on the library to be preloaded).
> 
> Oh, I recall it allows LD_PRELOAD on libraries that are placed in system
> directories and are themselves marked with the SUID bit.  IIRC, libc5's
> dynamic linker had that, too.

Yes, I don't recall if there are other cases it allows or not, but I
think as long as you avoid setting the suid bit on any libraries, the
allowance seems safe. On the other hand, any actual use of this
feature is probably insecure. Some issues that come to mind, assuming
suid libraries are present:

- After an upgrade, if the old library is left behind, an attacker can
  force the old version to be loaded in place of the new one in order
  to exploit bugs that are fixed in the new version.

- If there exists any suid library which contains symbol names which
  overlap with symbols that appear in other libraries, preloading it
  can interpose definitions for these symbols which have nothing to do
  with the actual functions/objects the application is trying to use
  (from another library) and thereby cause runaway incorrect behavior
  in an suid program.

I wouldn't be surprised if there are more related issues too..

Rich