mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Jeffrey Walton <noloader@gmail.com>
To: musl@lists.openwall.com
Cc: monk@unboiled.info
Subject: Re: [musl] $ORIGIN rpath expansion without /proc: code looks wrong
Date: Thu, 18 Nov 2021 14:42:22 -0500	[thread overview]
Message-ID: <CAH8yC8kOQvnzWqdxK1MRhHtb9bcfdgmXYrdjiTMMaZ4RMNB+6g@mail.gmail.com> (raw)
In-Reply-To: <CFT5E45O9EIZ.B4QEQ40XC711@mussels>

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.

Jeff

  parent reply	other threads:[~2021-11-18 19:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-17 14:04 Alexander Sosedkin
2021-11-17 17:00 ` Érico Nogueira
2021-11-17 19:25   ` Alexander Sosedkin
2021-11-18 19:15     ` Érico Nogueira
2021-11-17 20:01   ` Jeffrey Walton
2021-11-18 19:21     ` Érico Nogueira
2021-11-18 19:41       ` Alexander Sosedkin
2021-11-18 19:42       ` Jeffrey Walton [this message]
2021-11-18 20:30         ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH8yC8kOQvnzWqdxK1MRhHtb9bcfdgmXYrdjiTMMaZ4RMNB+6g@mail.gmail.com \
    --to=noloader@gmail.com \
    --cc=monk@unboiled.info \
    --cc=musl@lists.openwall.com \
    --subject='Re: [musl] $ORIGIN rpath expansion without /proc: code looks wrong' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).