[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Feb 2015 09:04:48 -0800
From: Paul Pluzhnikov <ppluzhnikov@...gle.com>
To: Rich Felker <dalias@...c.org>
Cc: oss-security@...ts.openwall.com
Subject: Re: Fixing the glibc runtime linker
On Fri, Feb 20, 2015 at 8:50 AM, Rich Felker <dalias@...c.org> wrote:
> On Fri, Feb 20, 2015 at 12:14:47AM -0800, Paul Pluzhnikov wrote:
>> 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.
Right. Except the picture may be slightly more complicated, e.g. the binary
has optional dependencies on libfoo.so and libbar.so, and the build uses
${CC} -Wl,-rpath=${LIBFOO_INSTALL}:${LIBBAR_INSTALL} ...
and one or both of _INSTALL paths may be empty in a given build.
The bad RPATH may also not be immediately discovered because e.g. the
developer has LD_LIBRARY_PATH set (which is common because developers often
use debug version of the library installed separately from release one).
All of this is to say that that is a relatively easy mistake to make.
I fully agree with you that a competent vendor will not make this mistake,
but there appears to be sufficient evidence that incompetent vendors
exist :-)
> 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.
Interesting notion. I am not sure how open binutils developers will be to it:
after all you explicitly asked for empty RPATH with command line argument.
Should GCC also refuse to compile 'execve(argv[1]);' unless a
-fyes-i-know-what-i-am-doing flag is given?
> 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.
Sounds good to me.
--
Paul Pluzhnikov
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.
