From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) by sourceware.org (Postfix) with ESMTPS id 934583858D39 for ; Tue, 9 Apr 2024 21:40:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 934583858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 934583858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::c2e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712698859; cv=none; b=PD8vPsdIfFLF0iuS1jyRrGDOLHZfyHxyWWPwO8ODSS+6VWBZgFqra25S8Mfn/jyhNE+yP7V94He+CFyJmJZ6/1crkULqxOQa5uEioj/nk3oEhx2Ry/a5pniULsqEm742VVsT5hAtTr7tC8T4zeBw4EZEgTmDJW2/Rhf6beS1344= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712698859; c=relaxed/simple; bh=kNuwEcbIKRch8o0e4zmOIvRjgw7jpbyGgPNeWtMz+pk=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=wiXN4Ok+sMZFtEQUwdtIvE0TfH+d5Cxc00aWizgFtJ8ZBFvg4khV2n1+zbXuOWAG+ly39wEwTRCDgHeKLXkITrXG+jvfUYcwXKf6sek0pxc5M9XEVT3AKItvNAkjyNBjWqJ1x+mHkJ7b0msd3xCozYsV+ZaYh9Sm6E7lkS8AkvY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oo1-xc2e.google.com with SMTP id 006d021491bc7-5aa28cde736so1847257eaf.1 for ; Tue, 09 Apr 2024 14:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712698857; x=1713303657; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=XS1VxhLVnEnKO0+848L9yFhg+onaIoViDfJuC7E9TsU=; b=f1a8cank0q4cVtVt6W2dDSlb/chLkMnTfL5hflDoWh3S6opydSzhQzfrzVug0TNBa7 EJHOFxb8dXO4VkDchktjKrXcPa2g2Mk03b815j7PEYE2JDtGkuEmOCebsmjAtIT7g1ms /PgviwuKXzLLYjYEVLA39kdSuK7gjNGx0kRB1NkvWEtptzQD60BVlsDkRK/LD5WOFewG NYPDbKXvT0KPtK3NzkpsGJq1JgcnMwyL9KByt1AVvzX4Hglo8CIV7+HvNrWk9xCyOQYK Qr8GBpVH1eanOM7Ksx9as0aVj7ytVA5T1Kzg/nl+3nrtA8PTl7YN4piL1Ht1eM+aPUmV 6uwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712698857; x=1713303657; h=content-transfer-encoding:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=XS1VxhLVnEnKO0+848L9yFhg+onaIoViDfJuC7E9TsU=; b=rqRNRv47X4qxYTV82gUlqpoCqqHodPJnjaXASfUoaBNa+jV6OZDB7/4NXDJ3odPqMS 7JANpCpBEl9gmii7WCmSOdRklPyd/45bFjHCnL6HQcrXN6xswcr+rkga5HkALSkYg5rI pxKOdXuWz8lOfJmuR3cY1RH3M+6mKqMKRsjBez6Jr4h+giwDMINUnE8jD7/OMPKRsuye JKvYijbAp3jPXsbotFfo5vxHnlykBzxuBBz1d35ETINMaY6DgT72A6CAWcpAGUIoWNZ/ yy0KRhhrQDpiRbzqPUhuHUOYoAngUxALaAYgmgsvNGMVBwTCRvpxZXSQmgd1Kj7Eb/2j AXbg== X-Forwarded-Encrypted: i=1; AJvYcCXzjojSqHuEqvKBFAIF/Tb3e+S+N8DoIlWRUBmWOb2CEgxbnaJ+uYO+lhI2lIPsS/qvdFbKmSsgBY5nHJPUj8s= X-Gm-Message-State: AOJu0YzdzHJ5sFG8DkxjAFtauXfsnVTua1vRpiIK6K0t5wsg3AZVSRY6 F+mEPF9BL7IHyESI18NMVX+o1vhwNyFi49T8iJQAnOONbTFZWf4xXRt7DjsMlSA82M/wBDBbURC eGZ8NbGTN4XZsSGIgHB6H4klGl7c= X-Google-Smtp-Source: AGHT+IE5Oj8yOHCC7hA5g/nCPVvruV5hIbAn0vuhL3mns9dDskXFHA3kfMXKm4TgyDvwBMuut4q1Q3hfKNyQYIBKGpY= X-Received: by 2002:a05:6820:1523:b0:5aa:2011:c5ff with SMTP id ay35-20020a056820152300b005aa2011c5ffmr1979907oob.3.1712698856841; Tue, 09 Apr 2024 14:40:56 -0700 (PDT) MIME-Version: 1.0 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> <41394737-6f2d-86e7-5742-e0a794f9f63c@suse.de> <4dd125546c920da4cc744a93f230917a7311c7fb.camel@gmail.com> <87h6gazafa.fsf@igel.home> <62A5C6AE-FE86-48EA-8E0D-E1B17959C8EA@comcast.net> In-Reply-To: <62A5C6AE-FE86-48EA-8E0D-E1B17959C8EA@comcast.net> Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Tue, 9 Apr 2024 17:40:45 -0400 Message-ID: Subject: Re: Sourceware mitigating and preventing the next xz-backdoor To: Paul Koning Cc: Jonathon Anderson , Andreas Schwab , Michael Matz , 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-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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 Tue, Apr 9, 2024 at 4:11=E2=80=AFPM Paul Koning via Gdb wrote: > > > On Apr 9, 2024, at 3:59 PM, Jonathon Anderson via Gcc = wrote: > > > > On Tue, Apr 9, 2024, 10:57 Andreas Schwab wrote= : > > > >> On Apr 09 2024, anderson.jonathonm@gmail.com wrote: > >> > >>> - This xz backdoor injection unpacked attacker-controlled files and r= an > >> them during `configure`. Newer build systems implement a build abstrac= tion > >> (aka DSL) that acts similar to a sandbox and enforces rules (e.g. the = only > >> code run during `meson setup` is from `meson.build` files and CMake). > >> Generally speaking the only way to disobey those rules is via an "esca= pe" > >> command (e.g. `run_command()`) of which there are few. This reduces th= e > >> task of auditing the build scripts for sandbox-breaking malicious inte= nt > >> significantly, only the "escapes" need investigation and they which > >> should(tm) be rare for well-behaved projects. > >> > >> Just like you can put your backdoor in *.m4 files, you can put them in > >> *.cmake files. > > > > > > CMake has its own sandbox and rules and escapes (granted, much more of > > them). But regardless, the injection code would be committed to the > > repository (point 2) and would not hold up to a source directory mounte= d > > read-only (point 3). > > Why would the injection code necessarily be committed to the repository? = It wasn't in the xz attack -- one hole in the procedures is that the kits = didn't match the repository and no checks caught this. In the Xz case, the victims should not have been able to execute a well known but modified *.m4 file. The *.m4 files should have been on the build machine already; or, the latest *.m4 files installed on the build machine via an updated Autoconf; or the latest serial-numbered *.m4 macro should have been fetched from a trusted source like GNU. They provide the provenance needed to allow their execution. In the browser world, content security policy (CSP) allows third party code to execute, assuming a script-src and an integrity tag. The provenance and integrity is enforced. > I don't see how a different build system would cure that issue. Instead,= there needs to be some sort of audit that verifies there aren't rogue or m= odified elements in the kit. Code provenance and code integrity was not enforced. Part of the problem is the Autotools design. It is from a bygone era. No one should be able to override a named, GNU supplied m4 macro. That's a bug, not a feature. Jeff