[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8kOQvnzWqdxK1MRhHtb9bcfdgmXYrdjiTMMaZ4RMNB+6g@mail.gmail.com>
Date: Thu, 18 Nov 2021 14:42:22 -0500
From: Jeffrey Walton <noloader@...il.com>
To: musl@...ts.openwall.com
Cc: monk@...oiled.info
Subject: Re: $ORIGIN rpath expansion without /proc: code looks wrong
On Thu, Nov 18, 2021 at 2:30 PM Érico Nogueira <ericonr@...root.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@...root.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.
Jeff
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
