From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B5C7F158041 for ; Sat, 30 Mar 2024 11:32:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 36E972BC022; Sat, 30 Mar 2024 11:32:40 +0000 (UTC) Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C80C22BC01A for ; Sat, 30 Mar 2024 11:32:39 +0000 (UTC) Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-2d476d7972aso38842701fa.1 for ; Sat, 30 Mar 2024 04:32:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711798358; x=1712403158; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KvVV1/5K84pulvzd0MDqzlbb/TaKWtwZiBmBOLFNARo=; b=IfbmsT7apW1mU3+tdh1BvE2zdj36eRtKPfIAT5l8odh5kjlm4jwGXpy1EU9egDE2Ad AQZlzzCqNBSvnTku/gNOqP+r4OB08OrDHTIVlxaOy+KH9PDGf7K3ee4sVvCr1lqXFdhA rff7KZ6UX8L5fD1hFDsOjoVS+cB6YWvdpONq7pq3j/4K7h/E5qGiaxcJZLzO5TcqyI1q d7s0g4TX/rN6PTMq0SPt66YAOOSkzT76EsjwJfmY/k+nVY+afV8Ko9w2I6Et0IhVLB4C 10Jq+IETfvZHdosdrlFaRv/ulXxXd6U+Vb+n/eTCpe0znZmC9MMxDnjEKK35gqTrPavB Rdlg== X-Gm-Message-State: AOJu0YzKcRUiFVr1Bu5kBufYmWJnsIjbKWFaLkWUp2YGtYunnWD9q3Ot e+35Dl+eFcmkncmDyZ4IWPy0KDa1g+9d3ZlbP3N4zYkYLNpcgTk2wjUpkaJ1X0fpOQHBKgM7UXB 0ev4S+NQTOh3nbBvSEzzrAySPLRAOOryQ X-Google-Smtp-Source: AGHT+IFZ13Ys0OpPrlj7WhZ+WZa/OQOO++3a8KCu5dgdGww5WnGCdzq8XiezTKkBbw1vwXOTo9blFVlB6dCTJ5t/HGo= X-Received: by 2002:a2e:a789:0:b0:2d6:c001:d87 with SMTP id c9-20020a2ea789000000b002d6c0010d87mr3927030ljf.8.1711798357549; Sat, 30 Mar 2024 04:32:37 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <20240329204315.3b29449b@Akita> <1671d927-55d5-6f01-2b54-b33981406945@gmail.com> In-Reply-To: <1671d927-55d5-6f01-2b54-b33981406945@gmail.com> From: Rich Freeman Date: Sat, 30 Mar 2024 07:32:26 -0400 Message-ID: Subject: Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 876fdfe9-38f9-45af-860e-8425aa781470 X-Archives-Hash: 7c48373bfe734acbc77dc42e509be682 On Sat, Mar 30, 2024 at 3:06=E2=80=AFAM Dale wrote: > > when I got to the part about it not likely to affect Gentoo, my level of = concern dropped significantly. If this is still true, there's no need to b= e concerned. "not likely" is the best way to characterize this. The exploit has not been fully analyzed, and it could have additional malicious behavior, either designed by its author, or perhaps even unintended by its author. I just wanted to toss in that caveat, but agree that the defaults deployed in Gentoo seem the most sensible for general use. There is nothing magical about xz - ANY widely-used library could have something like this embedded in it, and the attacker exploited what they had access to in order to go after a configuration that was going to be widely deployed and reachable (xz+deb/rpm+systemd+openssh). If the attacker had an intended target that used gentoo+openrc and access to something in our supply chain, this could have been a vulnerability that only impacted Gentoo. I think the big lesson here is that FOSS continues to suffer from core dependencies that are challenged for resources, and that efforts to fix this have to constantly keep up with the changing landscape. xz is going on 15 years old, but I don't think it was nearly as commonly used until fairly recently. libz has been a pretty well-known source of security flaws for ages (granted, usually not intentional like this). It isn't too surprising that in both cases compression libraries were targeted, as these are so widely depended on. This is getting tangential, but part of me wonders if there is a better way to do authentication. Programs like ssh tend to run as root so that they can authenticate users and then fork and suid to the appropriate user. Could some OS-level facility be created to allow unprivileged processes to run the daemons and then as part of the authentication process they can have the OS accept a controlled and minimal set of data to create the process as the new user and hand over the connection? PAM already has a large amount of control over the authentication process, so it seems like we just need to change the security context that this runs in. That's just brainstorming-level thinking though - there could be obvious issues with this that just haven't occurred to me. --=20 Rich