From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resdmta-h2p-564583.sys.comcast.net (resdmta-h2p-564583.sys.comcast.net [IPv6:2001:558:fd02:2446::d]) by sourceware.org (Postfix) with ESMTPS id 9ABB03858CDA for ; Tue, 2 Apr 2024 23:34:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9ABB03858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=comcast.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=comcast.net ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9ABB03858CDA Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:558:fd02:2446::d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712100900; cv=none; b=E2JOCg9vgkcTGtlce40jLZx4SEht9ed3xniX4bRoUs8cgWS4kpExV0s4+aBxfpodmoZoQgvXnigiROhKB8NInDw4byf9mPx+z10Hl9doYC0fZRDjWHSDJSp0pE/iijbFdDdQoqjyuBEkVAdvPqEEmbyBv9BuJYY7fxWC5G4tsIY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712100900; c=relaxed/simple; bh=4iqCfIt6jL0LOBa/UxJdKcLY/OLJ5sDhUv+VQHFKj+M=; h=DKIM-Signature:Mime-Version:Subject:From:Date:Message-Id:To; b=DbRCOU4qefZfEvlLDRNuyCtLLr/FxJdBkN+VOmKyYjfHqxzla0ydHjk2PKKTk8oV5HLt/KzxY4MHqX9n6e9VCVoeS3LtLuLds27JlaFA0jmeE9m9Xl8WN4suu794T+ZusUWOfKiPVab/jKJUhSuRwUJp1BZOn7AbbvGqydLmvw4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from resomta-h2p-554997.sys.comcast.net ([96.102.179.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resdmta-h2p-564583.sys.comcast.net with ESMTPS id rkKBrNturwc55rneZrYKtc; Tue, 02 Apr 2024 23:34:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1712100895; bh=3npAaIDbgtzuimwG+pnL5GifpZ3K0rG1ySD5MivmC70=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To:Xfinity-Spam-Result; b=2HN1Utl2vvMB1uVGiniE9xWOesUeFGyVgqnMkPAxRAlrl2GFLB/kE4wOXaHwBsKag AyDDIJrToxRR3SYLJWBcaOcLmjVH/1oVGLmIQ0nXw2FPMG1q/BUmNnrPqSWz8KdiSk vzQAr63RJMHF0MFNTNidBnGBMHAGICB/92SuhQXgNnqmBgp6jX9MLxpVjanF0vsmMk o2K8nQYhUag5E0QDAMC19M4ObjgaoWeNAO0Ym2yQaiVwyrC+Jw/CrCml5IBBwr+mst JbECuq2g/1PhyKEa1yBHtLL9YY9aUF7QqyRhwm8nmDk6p96Y96S8hcjJcmtK72DKaX Fz9gVmkjyEpNA== Received: from smtpclient.apple ([73.60.223.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-h2p-554997.sys.comcast.net with ESMTPSA id rne9rpxX1Az5HrneArh6F9; Tue, 02 Apr 2024 23:34:34 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Subject: Re: Sourceware mitigating and preventing the next xz-backdoor From: Paul Koning In-Reply-To: <077b9dd5-0df1-4384-a9d1-58e4283caf09@redhat.com> Date: Tue, 2 Apr 2024 19:34:28 -0400 Cc: Sandra Loosemore , Mark Wielaard , overseers@sourceware.org, gcc@gcc.gnu.org, binutils@sourceware.org, gdb@sourceware.org, libc-alpha@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <8FA2DDAB-E1BF-4DB8-B7DA-36D41281C1FA@comcast.net> References: <20240329203909.GS9427@gnu.wildebeest.org> <20240401150617.GF19478@gnu.wildebeest.org> <077b9dd5-0df1-4384-a9d1-58e4283caf09@redhat.com> To: Guinevere Larsen X-Mailer: Apple Mail (2.3696.120.41.1.8) X-CMAE-Envelope: MS4xfIHMldXbQeYaNL6o80VBNgYf6WhQ01KwS9s/ZfPlRKJNxHuDBZykAlYOhr3rjxSFemHQtwbwVX37KvmvyQgFSCpXICoOoiDRsl/fJ4nGDAcbWD4orczb ZS+7TmfU4f/phG9ex/b0lkMjX7t93v+yxVZJkVxU4z42/gNJw1sbGbqWT2w5lAvKgIKEOxc4+IkVA44qnfmAQ54VKH1lPLu2vz9WknBaZiDJUyOFGG7esrlR VMx2PNWPccb5BF4+5/+jfng4ETTt9o+kIJl5wbCZq62V6Gj6TkbFVRBbY/z+QnhFT26UjEGsI4bYLNPlidQl6RGsNIDmewBqN+qcurCTgrasHY9oCfsyCmeI o5Lqlvz5bIS+qYyanFVU3a+2rEcZ/jpHlYbjFZjIXpmL3CJ9TdZ0iFNHXBuVT/Iffno02KRF X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > On Apr 2, 2024, at 6:08 PM, Guinevere Larsen = wrote: >=20 > On 4/2/24 16:54, Sandra Loosemore wrote: >> On 4/1/24 09:06, Mark Wielaard wrote: >>> A big thanks to everybody working this long Easter weekend who = helped >>> analyze the xz-backdoor and making sure the impact on Sourceware and >>> the hosted projects was minimal. >>>=20 >>> This email isn't about the xz-backdoor itself. Do see Sam James FAQ >>> https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 >>> (Sorry for the github link, but this one does seem viewable without >>> proprietary javascript) >>>=20 >>> We should discuss what we have been doing and should do more to >>> mitigate and prevent the next xz-backdoor. There are a couple of >>> Sourceware services that can help with that. >>>=20 >>> TLDR; >>> - Replicatable isolated container/VMs are nice, we want more. >>> - autoregen buildbots, it should be transparent (and automated) how = to >>> regenerate build/source files. >>> - Automate (snapshot) releases tarballs. >>> - Reproducible releases (from git). >>>=20 >>> [snip] >>=20 >> While I appreciate the effort to harden the Sourceware infrastructure = against malicious attacks and want to join in on thanking everyone who = helped analyze this issue, to me it seems like the much bigger problem = is that XZ had a maintainer who appears to have acted in bad faith. Are = the development processes used by the GNU toolchain components robust = enough to cope with deliberate sabotage of the code base? Do we have = enough eyes available to ensure that every commit, even those by = designated maintainers, is vetted by someone else? Do we to harden our = process, too, to require all patches to be signed off by someone else = before committing? >>=20 >> -Sandra >>=20 >>=20 > What likely happened for the maintainer who acted in bad faith was = that they entered the project with bad faith intent from the start - = seeing as they were only involved with the project for 2 years, and = there was much social pressure from fake email accounts for the single = maintainer of XZ to accept help. >=20 > While we would obviously like to have more area maintainers and = possibly global maintainers to help spread the load, I don't think any = of the projects listed here are all that susceptible to the same type of = social engineering. For one, getting the same type of blanket approval = would be a much more involved process because we already have a = reasonable amount of people with those privileges, no one is dealing = with burnout and sassy customers saying we aren't doing enough. >=20 > Beyond that, we (GDB) are already experimenting with approved-by, and = I think glibc was doing the same. That guarantees at least a second set = of eyes that analyzed and agreed with the patch, I don't think = signed-off would add more than that tag (even if security was not the = reason why we implemented them). >=20 > --=20 > Cheers, > Guinevere Larsen > She/Her/Hers I agree that GDB, and for that matter other projects with significant = numbers of contributors, are not nearly as likely to be vulnerable to = this sort of attack. But I worry that xz may not be the only project = that's small enough to be vulnerable, and be security-relevant in not so = obvious ways. One question that comes to mind is whether there has been an effort = across the open source community to identify possible other targets of = such attacks. Contributions elsewhere by the suspect in this case are = an obvious concern, but similar scenarios with different names could = also be. That probably should be an ongoing activity: whenever some = external component is used, it would be worth knowing how it is = maintained, and how many eyeballs are involved. Even if this isn't done = by everyone, it seems like a proper precaution for security sensitive = projects. Another question that comes to mind: I would guess that relevant law = enforcement agencies are already looking into this, but it would seem = appropriate for those closest to the attacked software to reach out = explicitly and assist in any criminal investigations. paul