Date: Wed, 17 Nov 2021 15:01:54 -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 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. 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.