From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-c2p-570217.sys.comcast.net (resqmta-c2p-570217.sys.comcast.net [IPv6:2001:558:fd00:56::7]) by sourceware.org (Postfix) with ESMTPS id DDB353847718 for ; Wed, 3 Apr 2024 14:14:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DDB353847718 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 DDB353847718 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:558:fd00:56::7 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712153701; cv=none; b=cHU5MnXTb2lHLXWDZeoVm80y6ygiZQrP0cvETEHdDhNw+oi4VLkW8dnPDafy2+U7Uf/XVmDP2BdQLWl7aXywbGydJ/XxYnpDEt7ebfeK98S6tMXTup8uGxRFG6I2NcKU8+fX4lCDsyUg+oHzxEZsZOb2EJyFXU6Jg5fy9CtsDsQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712153701; c=relaxed/simple; bh=pJRhsL6sMe7bw0VcvJ6892Lq8BWpkLPSmwJ4HWawi1g=; h=DKIM-Signature:Mime-Version:Subject:From:Date:Message-Id:To; b=K68F1Z3zQxsl8mHXMVFIEbhksJZkTsVGvOFJzsPqLOHL6oYbzTFfhukyv3070hhKk8ZCcaxWX5n0yB/N27r/nedM5Varr2pfHeBEdrPKMR8mPTf+xpHQBiQeRQQVR61haeLjRtnwaaY4JOobTTbjM2Z0IWnohxhsKG/wH1cdw2E= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from resomta-c2p-539727.sys.comcast.net ([96.102.18.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resqmta-c2p-570217.sys.comcast.net with ESMTPS id rzfhrcxSgH4Sxs1OFrYkeI; Wed, 03 Apr 2024 14:14:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1712153699; bh=bNIjiOG6/JbJF0nmkBZgXkV1EchjhCeumEONTl78/As=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To:Xfinity-Spam-Result; b=QWrY5z6afkcFH1ywQxun2caYzbRnoXs8WeXDh98E0EzuGCKJZYCOL0fq9Fw3ZbKHZ tFuVscio5LLBufOoavW/9F6MiKF4RbQ2J9iSZ8SoZKo1CFlUC9GZhoqndspEDpgaPD L/f3P67HV8u/V9cLRBN7ADN4G4zbpgQCHhfl6nmh7jOFO3ozU5bXXEZu99XwOXYaEJ 4UYB1HhOuRgii4JV521BoTO6HPpS+QrQef0NOQ/87OwF2vO3L88YhXrE+EzIdikG1H KxU/9Ie0exEM161vgXj3sogf2Sb9K5odDUdC/YywzMn0zDvtZAnxx+diHf6gKTmUht Hqan29cUqDuXA== 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-c2p-539727.sys.comcast.net with ESMTPSA id s1OArm5iUSciDs1OBrbmtz; Wed, 03 Apr 2024 14:14:58 +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: <8e877d2f-01e0-c786-dea5-265edbdc0c07@suse.de> Date: Wed, 3 Apr 2024 10:14:53 -0400 Cc: Martin Uecker , Ian Lance Taylor , Paul Eggert , 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: References: <20240329203909.GS9427@gnu.wildebeest.org> <20240401150617.GF19478@gnu.wildebeest.org> <12215cd2-16db-4ee4-bd98-6a4bcf318592@cs.ucla.edu> <6239192ba9ff8aad0752309a54b633dc75a57c77.camel@tugraz.at> <8e877d2f-01e0-c786-dea5-265edbdc0c07@suse.de> To: Michael Matz X-Mailer: Apple Mail (2.3696.120.41.1.8) X-CMAE-Envelope: MS4xfJ4ksBy1HoiWGeN0XcRq4qBTIVmqxVTom8BX8X6GWSHdxTiWcPhdhm4UdR/epe1Qml5pg3HItnyrioLklHwubbu21WWMM5nmtB7b172/m6ILD3YQrTP+ ohRNXGmLxNkxm4xpv8t2r6J7BLktoekEMvJ5YjPyevzuZqP+DRkySE8OrlUAG1pKiyXnCGv9u4BuS5IrMIf+mm5xwuv7tH9+6L545yZbaZWahNPWhkV+9NTU SU9o/jteqQBOKYa8+6GpofcFd/JdjCYjAF6x9JFMx17CihnonvRvTA2mngb4Z9tJ065If5ueq45KJ+llux1zSQhbjs2CQVAyJp8Ma7/7vBThE4Yf8TF1chuH kv6Rjc1zubab6x6G7OIYJ5bebIR42OKF8Mp3ga74jUKttmmPd+IKAHnUCiymxiVDOzMzazlywz9CglyNNZxrKuGLdSYi6O35Mq/0C6vhQi681+7slGnCXMiU 4v98zgfThb2EThYvENBZC3+2dmOwlq5vAhMW6w== 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=ham 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 3, 2024, at 10:00 AM, Michael Matz wrote: >=20 > Hello, >=20 > On Wed, 3 Apr 2024, Martin Uecker via Gcc wrote: >=20 >>>> Seems reasonable, but note that it wouldn't make any difference to >>>> this attack. The liblzma library was modified to corrupt the sshd >>>> binary, when sshd was linked against liblzma. The actual attack >>>> occurred via a connection to a corrupt sshd. If sshd was running = as >>>> root, as is normal, the attacker had root access to the machine. = None >>>> of the attacking steps had anything to do with having root access >>>> while building or installing the program. >>=20 >> There does not seem a single good solution against something like = this. >>=20 >> My take a way is that software needs to become less complex. Do=20 >> we really still need complex build systems such as autoconf? >=20 > Do we really need complex languages like C++ to write our software in? = =20 > SCNR :) Complexity lies in the eye of the beholder, but to be honest = in=20 > the software that we're dealing with here, the build system or = autoconf=20 > does _not_ come to mind first when thinking about complexity. >=20 > (And, FWIW, testing for features isn't "complex". And have you looked = at=20 > other build systems? I have, and none of them are less complex, just=20= > opaque in different ways from make+autotools). >=20 > Ciao, > Michael. I would tend to agree with that even given my limited exposure to = alternatives. One aspect of the present attack that needs to be cured is that -- as I = understand it -- the open source repository was fine but the kit as = distributed had been subverted. In other words, the standard assumption = that the repository actually corresponds to the released code was not = valid. And furthermore, that it wasn't unusual for the kit to contain = different or additional elements, just that it wasn't supposed to differ = in malicious ways. One possible answer is for all elements of kits to be made explicitly = visible, though generated files probably don't want to be held in a = normal source control system. Another possible answer is for consumers = of kits to treat kits as suspect, and have them unpacked and examined -- = including any elements not source controlled -- before acceptance. I = think the first option is better because it exposes these additional = elements to ongoing scrutiny from the entire community, rather than only = one-time inspection by release managers who are probably quite pressed = for time. Either way, the reasons for these extra files to exist and the manner in = which they are supposed to be generated would need to be both well = documented and readily reproducible by outside parties. paul