[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Feb 2015 07:53:58 +0000
From: Tim Brown <tmb@...35.com>
To: oss-security@...ts.openwall.com
Cc: Paul Pluzhnikov <ppluzhnikov@...gle.com>,
Rich Felker <dalias@...c.org>
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 <dalias@...c.org> 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:
* https://www.nth-dimension.org.uk/blog.php?id=87
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
--
Tim Brown
<mailto:tmb@...35.com>
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.
