From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0Bm/M6NkDWbvgiEAWB0awg (envelope-from ) for ; Wed, 03 Apr 2024 10:16:03 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=U8sL+aTU; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D0D891E0C0; Wed, 3 Apr 2024 10:16:03 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C0A9C1E030 for ; Wed, 3 Apr 2024 10:16:01 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7CCF7384604F for ; Wed, 3 Apr 2024 14:16:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7CCF7384604F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1712153761; bh=bNIjiOG6/JbJF0nmkBZgXkV1EchjhCeumEONTl78/As=; h=Subject:In-Reply-To:Date:Cc:References:To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=U8sL+aTUmIgQ7puAE+eZBF6QjQXho/85IA8FRVyUohfZ5lwRtWZMGJ78d1rOQ/PA7 4InSo6tmoQ0DNENdLpKXRrAU5cqxwV9Hico53UpEzhTncowuMeSug/reNkAlx7YpSv 3pbdnXA3a+tNq6Eqf7Qjg9djUAcZh1xdYG0LrJS0= Received: from resqmta-c2p-570502.sys.comcast.net (resqmta-c2p-570502.sys.comcast.net [IPv6:2001:558:fd00:56::2]) by sourceware.org (Postfix) with ESMTPS id 26C41384645B for ; Wed, 3 Apr 2024 14:15:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 26C41384645B ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 26C41384645B ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712153702; cv=none; b=jB6CeS8WnC8sXM09vxYgniLeioCCQF946S05ru8ailu7M4dLvf3VMUiKTFtueIs/Ixv+BH/tz3Mj9co5gUOXUQFgFYEuhecCpU9Q0hs3y5K7v9bUmMC61xqPkkw2N/YHInCxgOY1yLclrZQXnCv7XtXPZjeTqsqdFN3+OWitbkg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712153702; c=relaxed/simple; bh=pJRhsL6sMe7bw0VcvJ6892Lq8BWpkLPSmwJ4HWawi1g=; h=DKIM-Signature:Mime-Version:Subject:From:Date:Message-Id:To; b=x8rcsMAx7zpYu/KrecqvTabOcu6dX4qq6PSlDSMWnAa++Ai/o6ROkesyxwCCOXlJZMwrC8VWEVy7UckuqsTpbZqbjTgNDkTsxMaYFM2XmPuOXaTS32q/gZHLH2ZIeOayqJeMrYcwXyBhItlMTSQ8C2QETAYBYSTDJWiUkrcPwQQ= 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-570502.sys.comcast.net with ESMTPS id s0xqrZGCQkncVs1OFr6WZh; Wed, 03 Apr 2024 14:14:59 +0000 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 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=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Paul Koning via Gdb Reply-To: Paul Koning Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" > 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