Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Feb 2015 07:53:58 +0000
From: Tim Brown <>
Cc: Paul Pluzhnikov <>,
 Rich Felker <>
Subject: Re: Fixing the glibc runtime linker

On Friday 20 February 2015 08:14:47 Paul Pluzhnikov wrote:
> On Thu, Feb 19, 2015 at 11:57 PM, Rich Felker <> wrote:
> > How is an empty or relative rpath easy?
> all: foo
> foo: foo.c
>         ${CC} -Wl,-rpath=${VAR} -o $@ $^
> If VAR is unset, or set to relative path, resulting binary will be "bad".
> Quoting original Tim's message:
> > Over the last couple of years I've spent a good deal of time dealing with
> > vendors who, for one reason or another have shipped binaries where it is
> > possible to inject "untrusted" code into running processes, notably but
> > not exclusively via DT_RPATH.
> I can easily believe that such binaries are fairly common.

That covers the DT_RPATH/DT_RUNPATH case adequately, here's a (similar) 
example for LD_LIBRARY_PATH:


The point is that I don't think it needs to be this way. As I said in my 
initial post, Solaris has had saner (although IMO not perhaps perfect) 
handling of this class of bug for years. If you look at the cases I've 
publicly reported over the last few years, Solaris wouldn't have been affected 
by any of them (despite what at least one vendor has said) because it does the 
sensible thing.

I'll certainly have another look at the non-priv'd case (I'm leaning towards 
having $RELATIVE (new) and $ORIGIN honoured for them (despite the fact that it 
compromises the basic premis a little)) but I don't see a good argument for 
not protecting setuid/setgid binaries in the manner described.

Having guaged appetite, I don't think the objections are insurmountable so 
it's worth progressing with.

I guess, having kicked this bug class for a while (and even put out a paper 
looking at the wider issue of linker behaviour), I'm trying to put my money 
where my mouth is. That's what we're supposed to do, no? Find fixes rather than 
just keep pointing out problems.

To Rich specifically, I'm keen to get some kind of fix adopted, so once I've had 
a chance to mull over the logging and necessary cases for relative paths a 
little more, I'll circulate a revised patch and we can kick it around further. 
I don't know what your thoughts are on MUSL, but I'd certainly prefer to get 
buy in from you guys, if at all possible.
Tim Brown

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

Powered by blists - more mailing lists

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.