From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) by sourceware.org (Postfix) with ESMTPS id 9C8623858CDA; Tue, 9 Apr 2024 21:40:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9C8623858CDA 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 9C8623858CDA Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::c2a ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712698859; cv=none; b=gh45QZa3ALsziVCF+kVMwi9SjsnmCrliompiTgbCL9jKgE+oBeBV3dkCAuxHP0oVJpodU5Lt4lrWQKNghP3ABw+SThnv6DVIJHWVOvibRUeI9zu8zQCUtwDxKQZntPYQ4GSx5EHu8NiJBpIvHNPuHT8EqzeYiTyK8XhCsCf0RM0= 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=pTkVFvSv21kCDegNs4G3dRSwNq6fvNctOEE/HC4xCqMvcRC7RykBcIcIPbFmxnrC+8dz+VtsEaKlgC6FDQxDjvxLku6CVWpuV/Z1o6kG/GLyYYrwNr1xsHRuFrdqAkY2cfzrGUmyyRE5ZlXq5b/Wn2+9OR9rQhp/4WjyMzM/WRE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oo1-xc2a.google.com with SMTP id 006d021491bc7-5aa400b917dso1608970eaf.0; 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=sourceware.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=H1Dk7CkMPlZGdqJqJ7C7FqMmLJj4qzsgKFGYxyI88EVgIfPxQ9ffYVrVywqu+w1lbZ 9lV2ixxXi+1X28r3kS3GUkTjSdVb5cWZ5fFA3qsdmnjMchSINvtaaQC5VwaE5jqMg34x ILf7StnFTHH5yYuIvaK7RMnxRMAXofUNdD7BDySkuUm2+NWBPyA/XJoCPqbbkEt9AD3q weuCQTF6etB2P7ceMX+fFOLGvZT6DXkcyay8TPlgTUX0yi27g5Ne5uAmW6Nk9F5WgTzt K60WZ7Qq+mQiEDxk/MC/4X0CKOYZylWwNIGC28H3QiuxPuzT9tRFz7VwjEQFBqQEP/I3 A2lQ== 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=qujV2PnQkxlvV6a4b1KNPvlkH3sVTuawsiIoqvziqr9SFsN737dNVBeGbBWz9hN+A5 4YIcr8ulBkTF/wgtZzHmwE6+DT5BsZNyY6etp9LQazRzgoRN06Ossg+QTEdoT2sWhlO4 6pwxAZoalr45t8G5ajK5Xr9Uy8r30XzthyykeCHvPJhMfqHyvPDLYbfcMUDJTGXwI5WV ehVO2wceusUhhC8wx6M9d1WovJgirQ0RwUU5LNaN2oqQAvXzb8w7LKdBcj+E1Y8hCr7Q 5hAgjORchSCvNt/HQ++bWNqiqDESoA8wOLcgjo3X1phTPpO5dqMjUr8Sh8S38SmkKmVq z3CA== X-Forwarded-Encrypted: i=1; AJvYcCXVhekQRPcWe1Tg3RVND0Nrx/f1r57ZsYFIzxKakFyVwlVNOjSl6lBjH6qh7KT/shNRh1J9fFQXHWuSJ+ohBHHgTYp3UUUPJuJQPc6tk0Qa2Reckt8Z50or3dydr65CijwPtYKb6lIxqHvCRHTndPba/3XmFJVQvylcXXE2eVjqg/9sSHZeHvU0TP0j8nE1UYw= X-Gm-Message-State: AOJu0YwRYYI+ETOiZ9yJPnP11Kpvws3a4ryFjCmtlcu2JbitVz5eVMAJ fDhOOJPewBlJw8lqQJ7GWmLzRccVGXP1sRayfThp58xxUjH/3wdqwjhMuFSi936GxIhX4KA2IEl Hx/2Jg+u+WRwtM6qPbXpPtGntUh0= 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.2 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