From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7962A4A1A for ; Sun, 14 Apr 2024 00:17:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=140.211.166.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713053860; cv=none; b=IqojyHxxasuE78ldjKr7SI4I/eSZIxMd6Y/rHGtNo5jg855xjqDXich+St69swZACSXIPC7ACRfa2HW8OsM+kboeI9xy7ucWeLezIeO2lu34IkOI8jW7AArJD56ynYIYZ0eBUoZMCV6PKQko5On0xenMb0l5pV9AXHr04uRDYSE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713053860; c=relaxed/simple; bh=qO51yFTO798C71tuXg3D52JPdaFQR7F5aA1i4p2P7/Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GAFfsYdXE98DaaV8vdnZnOyM8mzgF1D+AR2FB9SGgIH+0ycSv0TA5WosJl3VuoNu44Cqe1iEQDkjG86vlaiexoJZGlqk71eyVgjjqaPo1zypHd6NHr336+iUQB5hxfcQPOC4SSM4BZcw5Hg4odRm2G4m4+Nb+zHCGEHRTyq1R+E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b=KqaS5iPM; arc=none smtp.client-ip=140.211.166.136 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b="KqaS5iPM" Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 0CFAC60772 for ; Sun, 14 Apr 2024 00:17:38 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.4 X-Spam-Level: Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id oGDzoYvgGp0l for ; Sun, 14 Apr 2024 00:17:37 +0000 (UTC) X-Greylist: delayed 360 seconds by postgrey-1.37 at util1.osuosl.org; Sun, 14 Apr 2024 00:17:36 UTC DMARC-Filter: OpenDMARC Filter v1.4.2 smtp3.osuosl.org 9472C60765 Authentication-Results: smtp3.osuosl.org; dmarc=pass (p=none dis=none) header.from=mit.edu DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9472C60765 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256 header.s=outgoing header.b=KqaS5iPM Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=18.9.28.11; helo=outgoing.mit.edu; envelope-from=tytso@mit.edu; receiver= Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp3.osuosl.org (Postfix) with ESMTPS id 9472C60765 for ; Sun, 14 Apr 2024 00:17:36 +0000 (UTC) Received: from cwcc.thunk.org (pool-173-48-113-2.bstnma.fios.verizon.net [173.48.113.2]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 43E0BQaB005499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 13 Apr 2024 20:11:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1713053489; bh=rNOiQAS4Lvh4c8gAafYXoMIRCFIbHebZ3GCxVs5GVVM=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=KqaS5iPMeKCV8BxOvJwH+gcmDTEZ+TJeqs65CRWpmzx/ruD3fBTxYeKld8FM77Hv1 oRBkFQWuZ9cDOdetA/hP04J/es5xJqsSdADijczNWFsqqYsxfZ9mO9KioDWRJSDt0T JKRKYc3zFGdGS/cvGXTiVu/hM63Qh8+mzMF+gcvYSslroeWL/L5E7JqU37HrrhF0V1 xhxJSOJ+ASpjLkR5VInzrqUq7s+aGFG5nxDo0fQPxLMkIcETJb9dSryKqbnUVIVVgq NlEMrC2tEHyZZWocYWX11FpOhOHplxQdCT65gGKlJn1eluidfQiggU8C59cz7VRx1K cMo6O9EDMMRrg== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 0353615C0CB5; Sat, 13 Apr 2024 20:11:25 -0400 (EDT) Date: Sat, 13 Apr 2024 20:11:25 -0400 From: "Theodore Ts'o" To: James Bottomley Cc: "H. Peter Anvin" , "tech-board-discuss@lists.linuxfoundation.org" Subject: Re: xz meltdown/Lasse Collin Message-ID: <20240414001125.GF187181@mit.edu> References: <8205E91D-F15B-402D-9398-33E4FF4E4E62@zytor.com> <030a96cf36719d8a7ec702b9303616f89daed4bb.camel@HansenPartnership.com> <06A3D21F-58BD-40B5-9A18-0A90C9047CA3@zytor.com> <68255101309f2ac39927d47b3d527c4883a2e791.camel@HansenPartnership.com> Precedence: bulk X-Mailing-List: tech-board-discuss@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68255101309f2ac39927d47b3d527c4883a2e791.camel@HansenPartnership.com> On Sat, Apr 13, 2024 at 10:12:44AM -0400, James Bottomley wrote: > > I gave an idea for that above. But the first key step is pro-active > identification. The MO of the burnout attack was to try to make the > attacker the single help resource; people in this position tend not to > know they need to ask for other help. So the first step has to be pro- > active in looking for them (which is also useful for providing a risk > report about the entire ecosystem). It's important not to over-index on the specifics of how the xz-utils attack was carried out. Yes, this time the attack was carried out by trying to identify someone who was close to being burned out. It also involved generated files and autotools. But that's not the only way such an attack could be carried out. If we're talking about a nation-state with a vast amount of resources and patience, the next time the attack might involve someone just becoming a trusted contributor and contributing years of good work and reviews before trying to submit a change which introduces some other kind of back door or bug. Perhaps the next attack will involve getting an agent hired by a major AI chip vendor, and the backdoor will be hidden inside the proprietary binaries distributed by that AI chip vendor to download firmware into that company's GPU. (And if these propietary drivers and binaries are used by a large number of hyperscale cloud vendors, a backdoor into that GPU driver or the GPU's support binaries would be.... devastating.) That's not to say that we shouldn't find ways to better support https://xkcd.com/2347. Or that we interrogate whether autotools is the best long-term solution, or how to come up with a better solution without going down the systemd approach of "we only care about Linux and all other OS's are Not Our PRoblem). Or that we should have tools that look for differences between binaries built for distributions versus built out of the git tree, perhaps by looking for behavioral or performacne differences. But let's not over-focus on the burnout attack, or the "only activate if the build infrastructure is Debian or Fedora" attributes of what happened this time around. It is very likely that the next attempt to subvert software supply chain will be quite different. - Ted