Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Feb 2015 06:33:31 +0000
From: Tim Brown <tmb@...35.com>
To: oss-security@...ts.openwall.com
Cc: Stuart Gathman <stuart@...hman.org>
Subject: Re: Fixing the glibc runtime linker

On Thursday 19 February 2015 23:33:26 Stuart Gathman wrote:
> On 02/19/2015 05:19 PM, Tim Brown wrote:
> > What's the fix?
> > 
> > More often than not, the underlying issue is an empty element within the
> > DT_RPATH header or equivalent. Sometimes it's not, but even in those
> > cases, it is largely that one or more elements isn't qualifed (i.e. it
> > doesn't start with /). The attached patch fixes this, by ignoring any
> > elements of DT_RPATH, LD_LIBRARY_PATH that do not start with a /, and/or
> > junking any use of dlopen where the filename is likewise unqualified.
> > 
> > Won't this break stuff?
> > 
> > Maybe (certainly it is means a change to glibc behaviour), but more often
> > than not, the fact that a given binary currently works in an unsafe way
> > is a bug - and an exploitable one at that. Moreoever, Solaris has had a
> > similar sanitity check (in their case only for privileged setuid
> > binaries) for a good number of years without serious incident. I believe
> > we should be fixing software that exhibits the behaviour I've described,
> > but this patch will (I think) kill the bug class irrespective of that.
> 
> There needs to be a way to log the paths being ignored - so at least
> some people will have a clue as to why their program doesn't work. I'm
> not sure what that way is.

Probably something to take up with the glibc folk directly, but I could 
envisage using the LD_DEBUG infrastructure.

Tim
-- 
Tim Brown
<mailto:tmb@...35.com>

[ CONTENT OF TYPE application/pgp-signature SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ