Re: Fixing the glibc runtime linker

[Paul Pluzhnikov <ppluzhnikov () google com>]

On Fri, Feb 20, 2015 at 8:50 AM, Rich Felker <dalias () libc 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