From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id mJWqMQqjD2b/SAAAe85BDQ:P1 (envelope-from ) for ; Fri, 05 Apr 2024 09:06:51 +0200 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id mJWqMQqjD2b/SAAAe85BDQ (envelope-from ) for ; Fri, 05 Apr 2024 09:06:50 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1712300810; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=QSX5VpXe1opp24e/TotIZypUQ/WvmdBxXACExX6q1CA=; b=OEsMS0G0QLu8ncoMfugqQQCZ3sWkM67ZC24Byu5Yz098ch0GY84VVBh0dNFt5OCBB3WXQK J19GH9R5XrGQT34Gpz07bHgtaOt9edHLLqLUJu0qTzXRdBGiN3YcNG6dJeJ/D51MCkpQrR i30f+VqUtiNdmn8xJ1eXRCTumUvivcTdOhubK19panw8jwqxtsQTHdrFg4JoKO2rS90lKW BGDUvqpGnt3OnqlGLe4bJOb8qd+XCjhkak0mDhxj18f3uxPN+aS+wLcnZyZ5jBoeoL4Zo6 1c7qD5sIJfdIJMCdyTbVIwxlyatcbYFfuFWH2hnhzMBt7x4ocvix21vbO4RQiQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1712300810; a=rsa-sha256; cv=none; b=oybnvFYfxMuekyz2dD+hM7P5evxrZPXoJg1RJ6Omx9DA/KTbxY75qJs50HrIaMEXMT6UKX AWCCS4vmZ0TzIS+ib9k6Gz3+6nNfkKAINUy6SKzKZDLqQPeh1LbIsZL6gI0yhDKKhQMaFE WuIjDBeEg9EpiEtPaXns1mAEfdhxZdLdD0UFs+ZthA8Jq3TDl/Qla04H/HbqiE5MkWjHrk hm0a/+c6Bq/foQBM8kLM9lWGcyx25/sXLcgIPBn+EQ1A2TfbHCQBfgLoXkRBIRFvsk/n60 Z+pvk556hDv+6yGSx9swwhSoRc0meN6aewMuYt/NiNTwZ5Rbz+iFVGZkE8YCtQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 9BEC91531A for ; Fri, 5 Apr 2024 09:06:50 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rsdeN-0001GD-Id; Fri, 05 Apr 2024 03:06:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rsdeL-0001Fq-As; Fri, 05 Apr 2024 03:06:09 -0400 Received: from ns13.heimat.it ([46.4.214.66]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rsdeI-0006Iy-US; Fri, 05 Apr 2024 03:06:09 -0400 Received: from localhost (ip6-localhost [127.0.0.1]) by ns13.heimat.it (Postfix) with ESMTP id 183C230081F; Fri, 5 Apr 2024 07:06:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at ns13.heimat.it Received: from ns13.heimat.it ([127.0.0.1]) by localhost (ns13.heimat.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0oVXVvjZDRN; Fri, 5 Apr 2024 07:06:02 +0000 (UTC) Received: from bourrache.mug.xelera.it (unknown [93.56.171.217]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ns13.heimat.it (Postfix) with ESMTPSA id 16FD930081A; Fri, 5 Apr 2024 07:06:02 +0000 (UTC) Received: from roquette.mug.biscuolo.net (roquette [10.38.2.14]) by bourrache.mug.xelera.it (Postfix) with SMTP id AA8BB3084889; Fri, 5 Apr 2024 09:06:01 +0200 (CEST) Received: (nullmailer pid 6680 invoked by uid 1000); Fri, 05 Apr 2024 07:06:01 -0000 From: Giovanni Biscuolo To: Ricardo Wurmus Cc: Guix Devel , guix-security@gnu.org Subject: Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils) In-Reply-To: <87jzlck9xk.fsf@elephly.net> Organization: Xelera.eu References: <87ttkon4c4.fsf@protonmail.com> <8734s1mn5p.fsf@xelera.eu> <87jzlck9xk.fsf@elephly.net> Date: Fri, 05 Apr 2024 09:06:00 +0200 Message-ID: <87plv4l25j.fsf@xelera.eu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=46.4.214.66; envelope-from=g@xelera.eu; helo=ns13.heimat.it X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -8.46 X-Spam-Score: -8.46 X-Migadu-Queue-Id: 9BEC91531A X-Migadu-Scanner: mx12.migadu.com X-TUID: ssXhpE6YgVKR --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Ricardo, Ricardo Wurmus writes: > Giovanni Biscuolo writes: > >> So AFAIU using a fixed "autoreconf -fi" should mitigate the risks of >> tampered .m4 macros (and other possibly tampered build configuration >> script)? >> >> IMHO "ignoring" (deleting) pre-built build scripts in Guix >> build-system(s) should be considered... or is /already/ so? > > The gnu-build-system has a bootstrap phase, but it only does something > when a configure script does not already exist. We sometimes force it > to bootstrap the build system when we patch configure.ac. > > In previous discussions there were no big objections to always > bootstrapping the build system files from autoconf/automake sources. But AFAIU the boostrap is not always done, right? If so, given that there are no big objections to always bootstrap the build system files, what is the technical reason it's not done? > This particular backdoor relied on a number of obfuscations: > > - binary test data. Nobody ever looks at binaries. Yes, and the presence of binary data (e.g. for testing or other included media) is not something under downstream (Guix) control, so we have to live with it. No? > - incomprehensibility of autotools output. This one is fundamentally a > social problem and easily extends to other complex build systems. In > the xz case, the instructions for assembling the shell snippets to > inject the backdoor could hide in plain sight, just because configure > scripts are expected to be near incomprehensible. They contain no > comments, are filled to the brim with portable (lowest common > denominator) shell magic, and contain bizarrely named variables. Yes I understand this well, for this reason I call configure scripts near-binary-artifacts, kinda *.o files From=20a reproducibility and security POV this is a nightmare and no one should never ever trust such configure scripts > Not using generated output is a good idea anyway and removes the > requirement to trust that the release tarballs are faithful derivations > from the autotools sources, but given the bland complexity of build system > code (whether that's recursive Makefiles, CMake cruft, or the infamous > gorilla spit[1] of autotools) I don't see a good way out. I guess I miss the technical details about why it's not possible to _always_ bootstrap the build system files from autoconf/automake sources: do you have any reference documentation or technical article as a reference, please? > [1] > https://www.gnu.org/software/autoconf/manual/autoconf-2.65/autoconf.html#= History I'll study the autoconf history :-) >> Given the above observation that =C2=ABit is pragmatically impossible [.= ..] >> to peer review a tarball prepared in this manner=C2=BB, I strongly doubt= that >> a possible Makefile tampering _in_the_release_tarball_ is easy to peer >> review; I'd ask: is it feaseable such an "automated analysis" (see >> above) in a dedicated build-system phase? > > I don't think it's feasible. Since Guix isn't a regular user (the > target audience of configure scripts) it has no business depending on > generated configure scripts. It should build these from source. Maybe I misunderstand your argument or, more probably, I was too cryptic. I mean, Someone=E2=84=A2 is telling that moving the unpacking of = the backdoor object to a Makefile rule is an easy target for _automated_ analisys: is that someone wrong or is there a way to analyze a Makefile to answer "Which files have 'special' rules?" >> In other words: what if the backdoor was injected directly in the source >> code of the *official* release tarball signed with a valid GPG signature >> (and obviously with a valid sha256 hash)? > > A malicious maintainer can sign bad release tarballs. A malicious > contributor can push signed commits that contain backdoors in code. Oh yes, but it's way more harder to hide backdoors in code published as signed (signed?!?) commits in a DVCS. Obviously no security system is perfect, but Some=E2=84=A2 is (very) less perfect than others. :-) >> Do upstream developer communities peer review release tarballs or they >> "just" peer review the code in the official DVCS? > > Most do neither. I'd guess that virtually *nobody* reviews tarballs > beyond automated tests (like what the GNU maintainers' GNUmakefile / > maint.mk does when preparing a release). I guess that in "nobody" are included Guix package contributors and committers... Then I'd say that virtually *nobody* should trust tarball! :-O To be clear: I'm not suggesting that "tarball reviews" - that is, verify the /almost/ exact correspondence of the tarball with the corresponding DVCS commit - should be added as a requirement for contributors or maintainers... it would be too burdensome. >> Also, in (info "(guix) origin Reference") I see that Guix packages can h= ave a >> list of uri(s) for the origin of source code, see xz as an example [7]: >> are they intended to be multiple independent sources to be compared in >> order to prevent possible tampering or are they "just" alternatives to >> be used if the first listed uri is unavailable? > > They are alternative URLs, much like what the mirror:// URLs do. OK understood, thanks! [...] >> All in all: should we really avoid the "pragmatically impossible to be >> peer reviewed" release tarballs? > > Yes. I tend to agree! :-( Thank you! Giovanni =2D-=20 Giovanni Biscuolo Xelera IT Infrastructures --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmYPotkMHGdAeGVsZXJh LmV1AAoJENN9DqfOzDkSLxMP/1VFV75LRGPte5BKbVPjij/BuES8NyLiWBUm+VzB 5tAQ2tTUsJP7SvcGS4dOPhHmSWMPKkuSOZVZl6ymohpRSFtFyc3jEDLcxW9eecoY 10eSElCLXffvHpJmHGxGMvEbi9bynJIVgoaPceRLsOIgFoMC0sgWyLp5UOPXZlJx tF8v0zNOFvMpqBf34Sbq8baFPW0uwlF45VQnxxkcHnjjovj1R4KJtsJiJwoWlFg3 oBkfSM1WFix9eC8pHoeAaMiL20yzASMBb2cg/NX4zqIAJdqKa9sMVLu/7FABEYWh xWEU/UKSmjmIRO4WvMo6afm9aPq8rfsq0Ckx4tknJqNNSUVuS7GycXOEGCK+0zza ZEAPU6u7s3xlwM3Rkc7ckE+cwAHcXeaPWLMxT5KjoSQDuP1zkerzXtXReVLXQqQU jIplSpVNgtzm2y2Ua4C8fJ3am4XG6mgiDrx0hF2+2uPz+dwPpWoIFWYdLCxmEvyj XQxRX1DW+KIdh7jv00tgmTmGAGX56l3erPtYXxHzDxHqgG2KM1EWMWgXZzPq8i4/ UmUat69DekPWRqvC07fHGihAmrVB+Oj1o8fhzudl0T5+ZHRhLaPQqfvYZW+Tp5yt uIZaqki6UC9+uvtZw4zVw0kHlHIQmBjWAaI+itPQ4DkwEb+A1AnxnKes8UGzR9HS pTm8 =L8nV -----END PGP SIGNATURE----- --=-=-=--