From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25289 invoked from network); 18 Nov 2021 19:30:14 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 18 Nov 2021 19:30:14 -0000 Received: (qmail 3645 invoked by uid 550); 18 Nov 2021 19:30:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3599 invoked from network); 18 Nov 2021 19:30:11 -0000 X-Virus-Scanned: Debian amavisd-new at disroot.org Mime-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1637263798; bh=S4eOaNz0KIjcWCoCP8rZCiXBaFTYI5/avsidhH4FWIE=; h=To:Cc:Subject:From:Date:In-Reply-To; b=Wy2M2SE4+CUb6U7eJ8yq8prFjgcu3YTk1J7C4En5aDcYuEqpr8YnhttN7azFpwwaZ CFs3nvHwJOwCaAiZwk/xchVFtL10HsgnmmXnPamUgntWYNT9iIPnqakjkqszwBgg9S POVXCdEp6O986Svd5aC9tM+o0MXufBXmI3m9ZqTzT/a5VZsQcJ7yZACy+DF5JlrZ1o W35g9NlrPw6PVZmkuqU5/mnYRBwjG2Y14Rvi9mxEFmFxiwHzLn+GtDY/ClUoG0zbpw 4VnVK1QXywexlxPYtRwoezIblsaB+x7oX2QS1eg9RR8nw8E4PAI+Lt6CHSjX7QUt6p p/IKF3vLOaZjg== Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 To: Cc: From: =?utf-8?q?=C3=89rico_Nogueira?= Date: Thu, 18 Nov 2021 16:21:13 -0300 Message-Id: In-Reply-To: Subject: Re: [musl] $ORIGIN rpath expansion without /proc: code looks wrong On Wed Nov 17, 2021 at 5:01 PM -03, Jeffrey Walton wrote: > On Wed, Nov 17, 2021 at 12:09 PM =C3=89rico Nogueira > 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() treat= s > > 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... Furthermore, I don't think an unprivileged user should be able to unmount /proc unless they have called prctl(PR_SET_NO_NEW_PRIVS, 1), no? Which would make any "attacks" be directed at themselves. > > Jeff