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.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,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 26883 invoked from network); 18 Nov 2021 19:43:35 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 18 Nov 2021 19:43:35 -0000 Received: (qmail 7984 invoked by uid 550); 18 Nov 2021 19:43:32 -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 7947 invoked from network); 18 Nov 2021 19:43:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=eHxAUVH8fgHKGN9c21ybGyeCtPMo6EGP+Z/g84YdCCE=; b=MyEBLgtts04HbJMiXK572KL893j1NIejB3/fATAlrjaZEilJgNc9jTJKYgKTpqlotH PMTcAZI1kR6sQzvKeBP5vJ8ymvmBqQ4o35DCauE1Q7V0jA3N5R7H2uVjhFEaTG2++7O/ 7eEdyNXEZEMXbFewa1BwTplOrTTuPGKwUL6j/WwwnN3GdbTx75jNuoTkRfZKuk7GcxoV 4KaLGrfb5vVlSoGXUC9skrGx6K5AKZ4/+bL+LXjuWrFOYANMbs4V6mMKuAHIHqdNBbTJ M4saU6swoppHk3qiiXDrTfHHNQoG6Sd2AOq0zQ2TjsOnGcvwTtvS2UH3JDkxsjkgU/Uw xjYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=eHxAUVH8fgHKGN9c21ybGyeCtPMo6EGP+Z/g84YdCCE=; b=6eFS8+3inVTEWV3FmxBtGqdRooEHb+5QP6OfMda1blTRAyK+wLUE3VljT61CtOlCgm 9fNaQ+vBdjWfyzL/THasw4meOhfZRfNINKOjgM4SrlHLn6UdFuICB8z4wa0kV/l1DH8Q V505NSCyVe7C5TGrj2L5oFI4eGjESiMTN3BRC8BzKKPg//3QR9hjGljja92OaM9SslAZ agoUNgz4j0xADFZ/fK5z+/KF2GBxOO7EzXEByFUhpwB1sjxxXs5Ctrt+D+6OZj5Z5zvI qlrnThEZOl45hCb6gIMmbTcShEfrtxCc38yk2B8QYOR4hoLg/17rM/8r1kfXTNE0nQcy L9Uw== X-Gm-Message-State: AOAM53015DKPREIK9gF8J0dvluomRYMLawcPg5k4yRrn01Tjf3XSgx+k FnA5HaHUkIvrVMpYJkyIobI7zqx7HCAUdwLsrhV/dvQQpydPeQ== X-Google-Smtp-Source: ABdhPJxc+az5V8YDHNWPBcKOEq1hLeV+nYYRMRLDEommD6TD36ukwCgTwcZx0dsmLDpgb/D3xR/+HXqfaqYIQ9yuay8= X-Received: by 2002:a17:902:ac8e:b0:143:6e61:460 with SMTP id h14-20020a170902ac8e00b001436e610460mr69455369plr.85.1637264599257; Thu, 18 Nov 2021 11:43:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Walton Date: Thu, 18 Nov 2021 14:42:22 -0500 Message-ID: To: musl@lists.openwall.com Cc: monk@unboiled.info Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] $ORIGIN rpath expansion without /proc: code looks wrong On Thu, Nov 18, 2021 at 2:30 PM =C3=89rico Nogueira w= rote: > > 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() tre= ats > > > the RPATH entry as a single string, and does all $ORIGIN substitution= s > > > 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