From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id kP9nMOopI2CcYQAA0tVLHw (envelope-from ) for ; Wed, 10 Feb 2021 00:33:46 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id +H35K+opI2DKNQAA1q6Kng (envelope-from ) for ; Wed, 10 Feb 2021 00:33:46 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 32323940355 for ; Wed, 10 Feb 2021 00:33:46 +0000 (UTC) Received: from localhost ([::1]:54690 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9dRx-0007vY-6t for larch@yhetil.org; Tue, 09 Feb 2021 19:33:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50384) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9d3v-0001fM-58 for guix-devel@gnu.org; Tue, 09 Feb 2021 19:08:55 -0500 Received: from 102d.relay.hey.com ([204.62.115.202]:40851) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9d3t-0001hT-8O for guix-devel@gnu.org; Tue, 09 Feb 2021 19:08:54 -0500 Received: from hey.com (bigip-vip-new.rw-ash-int.37signals.com [10.20.0.24]) by 102.relay.hey.com (Postfix) with ESMTP id 93EF481F57 for ; Wed, 10 Feb 2021 00:08:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hey.com; s=heymail; t=1612915731; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=elNXkdh9hw1crGOhn7b2VJTPIX22UnLACao+8pSzF1A=; b=BtT4b6ZDlZoYChwPa6B+nrFtf8IA1Dwlbf4UgnWdveAIfVQsbccvl3Q1puAVuKwVPiRoKB ZmJOeBWdpm2tYZwmTAy0Hi20JQsdP3lQ+x2EViEXQf2s3E1pOHpxf3xCDSjb/9QFpm9AKx D9b0hS8TznN23KvEHmH4xyxflcCcz+jAzE1a5dEHtdNrZ+iAHQ673KkD62mq6jWeLbAnTQ G0klaoJhL77Hd2ox0CFtS6yrIY1A9g6XgzE75jkH/O0RtUJr9ocHYKAahFR06AZi/JgGCH xpGCeGN6tXfuLpocodTz92zcct78WA9KGUiSDXWCZz4jQPp7LxVhSa2Ibo1Wyw== Date: Wed, 10 Feb 2021 00:08:51 +0000 From: Ryan Prior To: Development of GNU Guix and the GNU System distribution Message-ID: <461926c3d053474dd7196c9ed8f59a45b8c9c82f@hey.com> Subject: Mitigating "dependency confusion" attacks on Guix users Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_602324138774a_583048240d6"; charset=UTF-8 Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=204.62.115.202; envelope-from=ryanprior@hey.com; helo=102d.relay.hey.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.06 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=hey.com header.s=heymail header.b=BtT4b6ZD; dmarc=pass (policy=quarantine) header.from=hey.com; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 32323940355 X-Spam-Score: -1.06 X-Migadu-Scanner: scn1.migadu.com X-TUID: OSZAsEjdHxZ5 ----==_mimepart_602324138774a_583048240d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Guix! I've been digesting this piece, published hours ago, describing dependency confusion attacks that revealed severe vulnerabilities at many major organizations: https://medium.com/@alex.birsan/dependency- confusion-4a5d60fec610 Guix users already have a few mitigations against this sort of attack. Most importantly, no substitute servers or channels are installed by default which allow arbitrary uploads by community contributors. That feature of the affected public registries (npm, pypi, rubygems) is so convenient, but contributes to this kind of attack. This is a great motivation for people to move to Guix from those other package systems. However, I'm still thinking about how to attack Guix users. Somebody who adds an internal channel for their own packages could still be vulnerable to a dependency confusion attack via a compromised or manipulated Guix maintainer. The target of the attack could install packages they believed would be provided by their internal channel but actually get another package provided upstream. The degree of vulnerability increases further with each channel used, with each channel maintainer becoming another potential vector of compromise. How can we make this kind of attack even more difficult? What comes to my mind is that we should encourage (require?) people to specify the channel name a package belongs to, if it's not the "guix" channel. So instead of referring to "python-beautifulsoup4" (ambiguous: is this from my channel or upstream Guix?) we say that "python- beautifulsoup4" always means that package from the "guix" channel and a version provided by my channel called "internal" needs to be called for explicitly, like "@internal/python-beautifulsoup4". Cheers, Ryan ----==_mimepart_602324138774a_583048240d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Guix! I've been digesting this piece, published hours ago, desc= ribing dependency confusion attacks that revealed severe vulnerabilities = at many major organizations: https://medium.com/@alex.birsan/dependency-c= onfusion-4a5d60fec610

Guix users already have a few mitigations ag= ainst this sort of attack. Most importantly, no substitute servers or cha= nnels are installed by default which allow arbitrary uploads by community= contributors. That feature of the affected public registries (npm, pypi,= rubygems) is so convenient, but contributes to this kind of attack. This= is a great motivation for people to move to Guix from those other packag= e systems.

However, I'm still thinking about how to attack Guix us= ers. Somebody who adds an internal channel for their own packages could s= till be vulnerable to a dependency confusion attack via a compromised or = manipulated Guix maintainer. The target of the attack could install packa= ges they believed would be provided by their internal channel but actuall= y get another package provided upstream.

The degree of vulnerabili= ty increases further with each channel used, with each channel maintainer= becoming another potential vector of compromise. How can we make this ki= nd of attack even more difficult?

What comes to my mind is that we= should encourage (require?) people to specify the channel name a package= belongs to, if it's not the "guix" channel. So instead of refe= rring to "python-beautifulsoup4" (ambiguous: is this from my ch= annel or upstream Guix?) we say that "python-beautifulsoup4" al= ways means that package from the "guix" channel and a version p= rovided by my channel called "internal" needs to be called for = explicitly, like "@internal/python-beautifulsoup4".

Chee= rs,
Ryan
----==_mimepart_602324138774a_583048240d6--