[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140614172411.GA12671@openwall.com>
Date: Sat, 14 Jun 2014 21:24:11 +0400
From: Solar Designer <solar@...nwall.com>
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 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@...king.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
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.
