[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140614182942.GL179@brightrain.aerifal.cx>
Date: Sat, 14 Jun 2014 14:29:42 -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 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
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.
