Re: [musl] $ORIGIN rpath expansion without /proc: code looks wrong

[Rich Felker <dalias@libc.org>]

On Thu, Nov 18, 2021 at 02:42:22PM -0500, Jeffrey Walton wrote:
> On Thu, Nov 18, 2021 at 2:30 PM Érico Nogueira <ericonr@disroot.org> wrote:
> >
> > On Wed Nov 17, 2021 at 5:01 PM -03, Jeffrey Walton wrote:
> > > On Wed, Nov 17, 2021 at 12:09 PM Érico Nogueira <ericonr@disroot.org>
> > > wrote:
> > > >
> > > > On Wed Nov 17, 2021 at 11:04 AM -03, Alexander Sosedkin wrote:
> > > > > ...
> > > > > Could somebody take a look at this and double-check that
> > > > > this codepath makes sense?
> > > >
> > > > It does, but it might not be as robust as you wish. fixup_rpath() treats
> > > > the RPATH entry as a single string, and does all $ORIGIN substitutions
> > > > in one go (what splits the string by ":" is open_path()). This means
> > > > that the entire RPATH entry containing $ORIGIN will be ignored if
> > > > /proc/self/exe can't be accessed, despite one or more of them not
> > > > depending on $ORIGIN.
> > >
> > > This has come up before on the list. It is different behavior from
> > > libc, and it may be CVE worthy if a down-level library is used when an
> > > updated library is available but lost because the RPATH/RUNPATH is
> > > discarded.
> >
> > I would file such a CVE on the distro packaging or system administration
> > rather than musl. The binaries you need to run so /proc is mounted
> > shouldn't be the sort that depend on dynamic RPATH using ${ORIGIN}
> > (rather than a static one or no RPATH at all), and any security fix
> > should be confirmed to actually work before being deployed...
> 
> If I had an actual failure for Musl on Alpine, I would post it to the
> Musl list and possibly OSSecurity. I don't use Alpine regularly, so I
> won't manufacture the problem just to complain.
> 
> But I have encountered the problem with Perl. Perl configuration does
> not handle CFLAGS and CXXFLAGS correctly, so it screwed up RPATH
> during build time. At runtime, Perl used a down-level bzip2 with an
> outsatnding CVE.
> 
> In Perl's case, Perl simply dropped '$ORIGIN', and '$ORIGIN/../lib'
> became just '/../lib', which became '/lib'. And the vulnerable bzip2
> library resided in /lib.
> 
> Also keep in mind the ELF Format specification does not provide
> authority to drop all RPATHs like Musl is doing. The ELF specification
> is very clear how the paths are evaluated.
> 
> The ELF specification says to try to find the shared object at the
> RPATH location. If the shared object does not exist, then move to the
> next location. If the shared object does not exist in any of the
> RPATHs, then move to LD_LIBRARY_PATHs. If the shared object does not
> exist in any of the LD_LIBRARY_PATHs, then move to /lib. The ELF
> specification does not say to discard all paths if the library is not
> found at a location. Also see the section "Shared Object Dependencies"
> in the ELF specification.

With the caveat that we do not claim conformance to these behaviors
(for example, RPATH intentionally always behaves with the new RUNPATH
semantics because the original RPATH ones were wrong), I agree that
this is a bug. Failure to resolve $ORIGIN should not cause the rest of
the RPATH to be discarded. It should either prevent *all* search (due
to inability to evaluate the intended path accurately), preventing the
library from loading at all if it has any dependencies that aren't
already loaded, or should cause just the affected components to be
skipped. I'm not sure which behavior is better. The former is in some
sense more correct/fail-safe (never load wrong thing), but since this
error condition can only happen when you don't have /proc available,
the friendlier behavior might be just skipping these components. This
could probably be achieved just by setting origin="/dev/null"
(pathname guaranteed to exist and not be a directory) in the error
path.

Rich