|
Message-ID: <20150220165041.GU23507@brightrain.aerifal.cx> 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.