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

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

Received: (at 48146) by debbugs.gnu.org; 6 May 2021 08:19:45 +0000
From debbugs-submit-bounces@debbugs.gnu.org Thu May 06 04:19:45 2021
Received: from localhost ([127.0.0.1]:37008 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1leZEX-0002cZ-9H
	for submit@debbugs.gnu.org; Thu, 06 May 2021 04:19:45 -0400
Received: from laurent.telenet-ops.be ([195.130.137.89]:36240)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maximedevos@telenet.be>) id 1leZEU-0002cT-Ib
 for 48146@debbugs.gnu.org; Thu, 06 May 2021 04:19:43 -0400
Received: from ptr-bvsjgyjmffd7q9timvx.18120a2.ip6.access.telenet.be
 ([IPv6:2a02:1811:8c09:9d00:aaf1:9810:a0b8:a55d])
 by laurent.telenet-ops.be with bizsmtp
 id 1LKg2500J0mfAB401LKgt4; Thu, 06 May 2021 10:19:41 +0200
Message-ID: <d19b01f9d94c3f12fb59ae7dad88dbea25b13220.camel@telenet.be>
Subject: Re: bug#48146: Getting diverted to non-updated branches: a
 limitation of the authentication mechanism?
From: Maxime Devos <maximedevos@telenet.be>
To: Ludovic Courtès <ludo@gnu.org>
Date: Thu, 06 May 2021 10:19:30 +0200
In-Reply-To: <874kfgj4xm.fsf@gnu.org>
References: <b3c137f53eb256d43267e2358874bd25e4686e32.camel@telenet.be>
 <874kfgj4xm.fsf@gnu.org>
Content-Type: multipart/signed; micalg="pgp-sha512";
 protocol="application/pgp-signature"; boundary="=-omHmrGd5rOsqRKm47qdS"
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=1620289181; bh=zKWBsFEf8Rqx7FUvXLUYVYw4q2aAcY53IZju12wtnPY=;
 h=Subject:From:To:Cc:Date:In-Reply-To:References;
 b=bxV0cUHguirlJmrBx5J97G8oqEc+s6biaHT1qgD8v31rqFSrfeagvqByE0XA97F1M
 1kHTk2pfW903BdufOAsXtzHqPahFfkOxK0eOcxoReZonBb8F9FjF3ckE6GoTvHzrep
 L6KDyPuNl1jmqJR3v8JYcajOpAKhVBw/UqIyhg5nj+HY/ZVkGgrpMfvMZQNgUFlcas
 dQUE6h3SNvaWk8kNLrTlf2P4mXKfNDmYtxHXZ3uNCV6ihKqBTYD6ceWnW/voOeTr7s
 Jmh7LuGPN87Ocg/fLY4iSv98UfkKakPvl4Ao5y8oBdq02Q/6VFFDQ1XFq/sOgNlDgd
 e5yYme3TkoaOw==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 48146
Cc: 48146@debbugs.gnu.org
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: -1.7 (-)

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

Ludovic Courtès schreef op wo 05-05-2021 om 22:34 [+0200]:
> Hi Maxime,
> 
> Maxime Devos <maximedevos@telenet.be> skribis:
> 
> >   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.
> 
> Note that the attacker doesn’t even need to do something as
> sophisticated as you describe: they can just tweak the repo such that
> the advertised tip of ‘master’ remains today’s commit for some time.

That would be the ‘indefinite freeze attack’.

unattended-service-type keeps a log somewhere I think?  If for some reason
the (very attentive) user decides to look at the log, they might find it suspicious
that the same "guix" store item is used everytime, and the attack could be detected.

Diverting the user to a branch that is occassionally updated wouldn't raise
such warnings.

(excerpt from my log) # I need to fix my configuration ...
guix time-machine: error: Git error: failed to connect to localhost: Connection refused
[2021-05-03T16:10:19+0200] starting upgrade...
command "/gnu/store/6nfv48k5cjlg0d3my6i6mgzy0vqnd7g8-guix-1.2.0-21.4dff6ec/bin/guix" "time-machine" "-C" "/gnu/store/pm2ra4xkmahca79vpcjk8q0blxpi8pza-channels.scm" "--" "system" "reconfigure"
"/gnu/store/a01pi7yx4zw88cijfr3ml4hl2pn29ncz-butterfly-config.scm" failed with status 1
guix time-machine: error: Git error: failed to connect to localhost: Connection refused
[2021-05-05T12:03:56+0200] starting upgrade...
command "/gnu/store/6nfv48k5cjlg0d3my6i6mgzy0vqnd7g8-guix-1.2.0-21.4dff6ec/bin/guix" "time-machine" "-C" "/gnu/store/pm2ra4xkmahca79vpcjk8q0blxpi8pza-channels.scm" "--" "system" "reconfigure"
"/gnu/store/a01pi7yx4zw88cijfr3ml4hl2pn29ncz-butterfly-config.scm" failed with status 1
(end of excerpt)

The ‘indefinite freeze attack’ is a real attack, but not what I'm describing here.

> The blog post Leo mentioned discusses this problem and it’s not
> addressed per se.  If specific users are targeted, as in your scenario,
> it could be hard to detect.
> 
> But then again, I’d argue it’s beyond our threat model: there are other
> ways, possibly easier, to target individuals.

‘We’ can extend the threat model and further restrict how an attacker could
target individuals or groups. If you know of easier methods to target
individuals, please tell, maybe ‘we’ can patch guix to thwart them as well.

The existence of easier attack methods shouldn't stop us from stopping the
more complicated and/or difficult attack methods.

> If we assume the attacker is not targeting specific individuals but
> rather the whole user base, the attack can still be carried out but it
> wouldn’t go undetected for long.

I would prefer that the attack cannot be carried out _at all_. 
Requiring "guix pull --allow-downgrades" after a diversion attack
doesn't seem ideal.

> The “reference state log” mentioned in the blog post could help.

> It’s an interesting idea.  It addresses the scenario you described
> (redirecting users to a different branch) but it doesn’t address the
> more general indefinite freeze attack.  

I see ‘redirecting users to a branch they shouldn't use’ as a separate attack
from the ‘indefinite freeze attack’. My proposed attack method was a mixture
of both.

The general ‘indefinite freeze attack’ doesn't seem solvable, but the more
specific related attack ‘redirecting users to a branch they shouldn't
use’ _is_ solvable. Not being able to solve the complete problem shouldn't
stop ‘us’ from solving parts of the problem.

> I'm not sure it's worth focusing on this specific case.

I don't see how we could solve the ‘indefinite freeze attack’ in its full
generality, but this specific case seems solvable.

> Something like the “reference state log” would
> help address the general case.
>
> Thoughts?

I need to take a look at what this ‘reference state log’ is.

Greetings,
Maxime.

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

Send a report that this bug log contains spam.