Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 14 Jun 2014 12:30:26 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Binaries compiled with musl (1.1.2) are vulnerable to an
 ancient ldd exploit

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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.