#48146 - Getting diverted to non-updated branches: a limitation of the authentication mechanism?

Package	Source(s)		Maintainer(s)
guix		PTS Buildd Popcon

Message #5 received at submit@debbugs.gnu.org (full text, mbox, reply):

Received: (at submit) by debbugs.gnu.org; 1 May 2021 21:40:26 +0000
From debbugs-submit-bounces@debbugs.gnu.org Sat May 01 17:40:26 2021
Received: from localhost ([127.0.0.1]:38553 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1lcxLd-0005r4-TC
	for submit@debbugs.gnu.org; Sat, 01 May 2021 17:40:26 -0400
Received: from lists.gnu.org ([209.51.188.17]:42592)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maximedevos@telenet.be>) id 1lcxLc-0005qy-3x
 for submit@debbugs.gnu.org; Sat, 01 May 2021 17:40:24 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:42534)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <maximedevos@telenet.be>)
 id 1lcxLb-0004qV-Sj
 for bug-guix@gnu.org; Sat, 01 May 2021 17:40:23 -0400
Received: from laurent.telenet-ops.be ([2a02:1800:110:4::f00:19]:48774)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <maximedevos@telenet.be>)
 id 1lcxLU-0007xV-HN
 for bug-guix@gnu.org; Sat, 01 May 2021 17:40:23 -0400
Received: from [172.20.10.4] ([213.119.201.119])
 by laurent.telenet-ops.be with bizsmtp
 id zZgC240012b47od01ZgCDQ; Sat, 01 May 2021 23:40:12 +0200
Message-ID: <b3c137f53eb256d43267e2358874bd25e4686e32.camel@telenet.be>
Subject: Getting diverted to non-updated branches: a limitation of the
 authentication mechanism?
From: Maxime Devos <maximedevos@telenet.be>
To: bug-guix@gnu.org
Date: Sat, 01 May 2021 23:40:01 +0200
Content-Type: multipart/signed; micalg="pgp-sha512";
 protocol="application/pgp-signature"; boundary="=-9gxzzqhwCtITndA9DAW6"
User-Agent: Evolution 3.34.2 
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21;
 t=1619905212; bh=6vz2LBIFef+buOEjAGWyf9qTvlARWkn/UGhTVhcPo40=;
 h=Subject:From:To:Date;
 b=Qb9C1WBNeq1o0ALvMTknBMISIN3urBitMLvcvSgB9M7elv2MbBHj7yPMD94bDz0of
 pEX6zybgZRJ1fVNfWb1AE8/xU+obBHg9RDYKJr09YdzqiQJOsFMiGfsJHGnR8yOvew
 QEABt+Rh064dCEJPIvw3rvAGBGK1vErhiJKYh6+uvk0zpvTTRM2FDr+wANwqWAknIv
 QW3a3wgb+6a9nz9iZMAW6tpawag6zzWANUcY4Y7eF5kOQ0VGUrG8xqvlTvkDM4enh2
 tcpPX1tSUCtxLEp8UjxbhDhklOhNDN2Xjfgo/MpqXSXHTIDxOQVv829Go4LBSM9Qyw
 wLqFXsUXUVaKg==
Received-SPF: pass client-ip=2a02:1800:110:4::f00:19;
 envelope-from=maximedevos@telenet.be; helo=laurent.telenet-ops.be
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 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, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

[Message part 1 (text/plain, inline)]

Tags: + security

Hi guix,

Consider the following situation:

Premises:
  1. There are no known security vulnerabilities known
     to the attacker at the moment.
  2. Thus, the attacker instead will try to trick the system
     of the user into not updating, and exploit vulnerabilities
     once they become known.
  3. The user relies on unattended-service-type or similar for automatic upgrades.
  4. The attacker can subvert the savannah repository, but cannot forge commit
     signatures.
  5. The user is at commit A. There is a correctly-signed commit C on, say, core-updates,
     such that:  C comes after A, but C is not yet in master for the foreseable future.

Method:
  6. The attacker subverts savannah, replacing the tip of 'master' with 'C'.
     To avoid detection, this subverted master is only served to the targetted users.
  7. The targetted users' systems' unattended-service-type
     do their equivalent of "guix pull && guix system reconfigure ...".
  8. The targetted systems are now on core-updates, which does not receive timely
     security updates.
  9. On future automatic upgrades, the users' systems will stay on core-updates,
     without any obvious indication something is wrong.  (Aside from recompilations,
     maybe the user's machine has 40GiB RAM, dozens of processors and sits in some
     data centre where the user won't notice the sound of the fans.)
 10. A vulnerability is discovered (and fixed) and there is a blog post or something!
     The attacker is late to the party.
 11. Unfortunately for the user, the automatic upgrade does not fix the vulnerability
     on the user's system, as vulnerabilities are not patched on core-updates.
 12. The attacker reads the blog post about the vulnerability on their own leisure,
     and can take all time they need to exploit the users' systems.

Proposal for a fix:
 13. Find a volunteer to actually implement this.
 14. When creating branches that do not receive timely security updates,
     such as wip-gnome, core-updates and staging, add a line

     Authentication-Allow-Automatic-Follow: no (core-updates)

     to the commit message.
 15. When updating guix from a commit A to commit B, additionally verify
     whether there exists a path from A to B that does _not_ have a 

     Authentication-Allow-Automatic-Follow: no [branch]

     line.  If no such path exists, bail out and tell the user something
     like:

     error: Refusing to switch to the branch 'branch'!

     This usually means someone is trying to trick you into
     not receiving timely security updates! Please report this
     incident to #guix on freenode, or at bug-guix@gnu.org.

     It is safe to simply run "guix pull" again later.
 16. If there is a path from A to B that _does_ have a 

     Authentication-Allow-Automatic-Follow: no [branch]

     line, and another path that does _not_ have such a line,
     that means the branch has been merged, which is totally fine,
     so no error message is required in that case.

 17. This proposal assumes the attacker eventually gives up,
     such that "guix pull" will work again before a vulnerability
     is found (and exploited) on 'master'.

Greetings,
Maxime.

[signature.asc (application/pgp-signature, inline)]

Display info messages

Send a report that this bug log contains spam.

debbugs.gnu.org maintainers <help-debbugs@gnu.org>. Last modified: Sun Dec 22 03:59:58 2024; Machine Name: wallace-server

GNU bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

#48146 Getting diverted to non-updated branches: a limitation of the authentication mechanism?