[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABz95_B0_wambPrRsMCh5VpLYc1S6kODXu+YHz-B4SgtAYrsjw@mail.gmail.com>
Date: Sat, 14 Jun 2014 17:10:40 +0100
From: Steven Honeyman <stevenhoneyman@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Binaries compiled with musl (1.1.2) are vulnerable to an
ancient ldd exploit
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@...c.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
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.
