[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Feb 2015 11:50:41 -0500
From: Rich Felker <dalias@...c.org>
To: Paul Pluzhnikov <ppluzhnikov@...gle.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: Fixing the glibc runtime linker
On Fri, Feb 20, 2015 at 12:14:47AM -0800, 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".
If the rpath is needed for the binary to work, this should result in
immediate failure when you try to run it, which would be detected and
corrected before it becomes an issue.
If it's not needed for the binary to work, this is a huge incompetence
or policy failure issue that's not going to be fixed by restricting
RPATH. And it would probably be better solved by having ld produce
warnings for relative or blank RPATH (or even refusing to generate
such without an additional override option) rather than by potentially
breaking existing binaries.
Aside from that, I'm not fundamentally opposed to restricting relative
RPATH in suid binaries (or rather AT_SECURE), but it should not be
restricted in other cases. If it is restricted in the suid case, I
believe the correct way is refusing to run the binary at all. Just
ignoring the RPATH will possibly result in the wrong libraries being
loaded, which could itself lead to vulnerabilities.
Further discussion really should take place on libc-alpha or perhaps
by opening a bug on the glibc bug tracker ("ld.so accepts unsafe
relative RPATHS when running suid programs").
Rich
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.
