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:30:41 +0000
From: Tim Brown <>
Cc: Paul Pluzhnikov <>
Subject: Re: Fixing the glibc runtime linker

On Friday 20 February 2015 01:38:31 Paul Pluzhnikov wrote:
> On Thu, Feb 19, 2015 at 2:19 PM, Tim Brown <> wrote:
> > 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?
> FWIW, relative RPATHs are quite fundamental to our test execution
> environment, and any patch that unconditionally ignores them would
> have to be reverted in our tree.

That's useful to know. Is that for setuid binaries or more generally? As I 
noted, it would be dead easy only to use the part of the patch that rejects 
them for the former only. Although as I said, that offers less protection. 
Would that make the patch more consumable? Another option would be to have 
something like /etc/suid-debug which could flag that an override is in 

> Also, don't you want to discuss this on libc-alpha? oss-security could
> be all for it, but without buy-in from libc-alpha your patch is
> unlikely to be going anywhere.

I'm intending to, but getting security folk, who may well wear slightly more 
positive hats to begin with, to review it, seemed like a safe place to start. 
I can well imagine pursuading the glibc folk will be more difficult :/.

Tim Brown

Download attachment "signature.asc " of type "application/pgp-signature" (820 bytes)

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