GNU logs - #48146, boring messages

Message sent to bug-guix@HIDDEN:

Subject: bug#48146: Getting diverted to non-updated branches: a limitation of the authentication mechanism?
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sat, 01 May 2021 21:41:01 +0000
Resent-Message-ID: <handler.48146.B.161990522622514 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 48146 <at> debbugs.gnu.org
Message-ID: <b3c137f53eb256d43267e2358874bd25e4686e32.camel@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
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
Received-SPF: pass client-ip=2a02:1800:110:4::f00:19;
 envelope-from=maximedevos@HIDDEN; 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-BeenThere: debbugs-submit <at> 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 <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

--=-9gxzzqhwCtITndA9DAW6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 up=
grades.
  4. The attacker can subvert the savannah repository, but cannot forge com=
mit
     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 forese=
able 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 target=
ted 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-upd=
ates,
     without any obvious indication something is wrong.  (Aside from recomp=
ilations,
     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 vul=
nerability
     on the user's system, as vulnerabilities are not patched on core-updat=
es.
 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=20

     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@HIDDEN

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

     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.

--=-9gxzzqhwCtITndA9DAW6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYI3KsRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7jZ+APwPa0s35fCNdDuO4iyCBmreghoV
jgQhJr6loQ4MXPulJwEAiHYVRvw+xjzN5ifDXzUloz1EpveaZHsT3dbcJDeRaQQ=
=VMkP
-----END PGP SIGNATURE-----

--=-9gxzzqhwCtITndA9DAW6--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Maxime Devos <maximedevos@HIDDEN>
Subject: bug#48146: Acknowledgement (Getting diverted to non-updated
 branches: a limitation of the authentication mechanism?)
Message-ID: <handler.48146.B.161990522622514.ack <at> debbugs.gnu.org>
References: <b3c137f53eb256d43267e2358874bd25e4686e32.camel@HIDDEN>
X-Gnu-PR-Message: ack 48146
X-Gnu-PR-Package: guix
X-Gnu-PR-Keywords: security
Reply-To: 48146 <at> debbugs.gnu.org
Date: Sat, 01 May 2021 21:41:01 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guix@HIDDEN

If you wish to submit further information on this problem, please
send it to 48146 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
48146: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D48146
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guix@HIDDEN:

Subject: bug#48146: Getting diverted to non-updated branches: a limitation of the authentication mechanism?
Resent-From: Leo Famulari <leo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sun, 02 May 2021 04:10:01 +0000
Resent-Message-ID: <handler.48146.B48146.16199286003553 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Maxime Devos <maximedevos@HIDDEN>
Cc: 48146 <at> debbugs.gnu.org
Date: Sun, 2 May 2021 00:09:50 -0400
From: Leo Famulari <leo@HIDDEN>
Message-ID: <YI4mDjRZGFfLEzja@HIDDEN>
References: <b3c137f53eb256d43267e2358874bd25e4686e32.camel@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b3c137f53eb256d43267e2358874bd25e4686e32.camel@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

On Sat, May 01, 2021 at 11:40:01PM +0200, Maxime Devos wrote:
> Tags: + security
> 
> Hi guix,
> 
> Consider the following situation:

Check this blog post and The Update Framework's concept of "indefinite
freeze attacks", which I think is what you are describing:

https://guix.gnu.org/en/blog/2020/securing-updates/
https://theupdateframework.io/ (check the "specification")

Message sent to bug-guix@HIDDEN:

Subject: bug#48146: Getting diverted to non-updated branches: a limitation of the authentication mechanism?
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Wed, 05 May 2021 20:35:02 +0000
Resent-Message-ID: <handler.48146.B48146.162024686416394 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Maxime Devos <maximedevos@HIDDEN>
Cc: 48146 <at> debbugs.gnu.org
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
References: <b3c137f53eb256d43267e2358874bd25e4686e32.camel@HIDDEN>
Date: Wed, 05 May 2021 22:34:13 +0200
In-Reply-To: <b3c137f53eb256d43267e2358874bd25e4686e32.camel@HIDDEN>
 (Maxime Devos's message of "Sat, 01 May 2021 23:40:01 +0200")
Message-ID: <874kfgj4xm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hi Maxime,

Maxime Devos <maximedevos@HIDDEN> skribis:

>   5. The user is at commit A. There is a correctly-signed commit C on, sa=
y, core-updates,
>      such that:  C comes after A, but C is not yet in master for the fore=
seable 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 targ=
etted 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 receiv=
e timely
>      security updates.
>   9. On future automatic upgrades, the users' systems will stay on core-u=
pdates,
>      without any obvious indication something is wrong.  (Aside from reco=
mpilations,
>      maybe the user's machine has 40GiB RAM, dozens of processors and sit=
s 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 o=
r something!
>      The attacker is late to the party.
>  11. Unfortunately for the user, the automatic upgrade does not fix the v=
ulnerability
>      on the user's system, as vulnerabilities are not patched on core-upd=
ates.

Note that the attacker doesn=E2=80=99t even need to do something as
sophisticated as you describe: they can just tweak the repo such that
the advertised tip of =E2=80=98master=E2=80=99 remains today=E2=80=99s comm=
it for some time.

The blog post Leo mentioned discusses this problem and it=E2=80=99s not
addressed per se.  If specific users are targeted, as in your scenario,
it could be hard to detect.

But then again, I=E2=80=99d argue it=E2=80=99s beyond our threat model: the=
re are other
ways, possibly easier, to target individuals.

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=E2=80=99t go undetected for long.  The =E2=80=9Creference state log=
=E2=80=9D mentioned in
the blog post could help.

> 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=20
>
>      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@HIDDEN
>
>      It is safe to simply run "guix pull" again later.
>  16. If there is a path from A to B that _does_ have a=20
>
>      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.

It=E2=80=99s an interesting idea.  It addresses the scenario you described
(redirecting users to a different branch) but it doesn=E2=80=99t address the
more general indefinite freeze attack.  I=E2=80=99m not sure it=E2=80=99s w=
orth focusing
on this special case.  Something like the =E2=80=9Creference state log=E2=
=80=9D would
help address the general case.

Thoughts?

Thanks for thinking through it!

Ludo=E2=80=99.

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#48146: Getting diverted to non-updated branches: a limitation of the authentication mechanism?
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 06 May 2021 08:20:01 +0000
Resent-Message-ID: <handler.48146.B48146.162028918510083 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 48146
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: security
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: 48146 <at> debbugs.gnu.org
Received: via spool by 48146-submit <at> debbugs.gnu.org id=B48146.162028918510083
          (code B ref 48146); Thu, 06 May 2021 08:20:01 +0000
Received: (at 48146) by debbugs.gnu.org; 6 May 2021 08:19:45 +0000
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 <at> debbugs.gnu.org>)
	id 1leZEX-0002cZ-9H
	for submit <at> 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@HIDDEN>) id 1leZEU-0002cT-Ib
 for 48146 <at> 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@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
Date: Thu, 06 May 2021 10:19:30 +0200
In-Reply-To: <874kfgj4xm.fsf@HIDDEN>
References: <b3c137f53eb256d43267e2358874bd25e4686e32.camel@HIDDEN>
 <874kfgj4xm.fsf@HIDDEN>
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-BeenThere: debbugs-submit <at> 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 <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)


--=-omHmrGd5rOsqRKm47qdS
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Ludovic Court=C3=A8s schreef op wo 05-05-2021 om 22:34 [+0200]:
> Hi Maxime,
>=20
> Maxime Devos <maximedevos@HIDDEN> skribis:
>=20
> >   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 fo=
reseable future.
> >=20
> > Method:
> >   6. The attacker subverts savannah, replacing the tip of 'master' with=
 'C'.
> >      To avoid detection, this subverted master is only served to the ta=
rgetted 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 rece=
ive 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 re=
compilations,
> >      maybe the user's machine has 40GiB RAM, dozens of processors and s=
its 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-u=
pdates.
>=20
> Note that the attacker doesn=E2=80=99t even need to do something as
> sophisticated as you describe: they can just tweak the repo such that
> the advertised tip of =E2=80=98master=E2=80=99 remains today=E2=80=99s co=
mmit for some time.

That would be the =E2=80=98indefinite freeze attack=E2=80=99.

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 su=
spicious
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: Connec=
tion 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 w=
ith status 1
guix time-machine: error: Git error: failed to connect to localhost: Connec=
tion 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 w=
ith status 1
(end of excerpt)

The =E2=80=98indefinite freeze attack=E2=80=99 is a real attack, but not wh=
at I'm describing here.

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

=E2=80=98We=E2=80=99 can extend the threat model and further restrict how a=
n attacker could
target individuals or groups. If you know of easier methods to target
individuals, please tell, maybe =E2=80=98we=E2=80=99 can patch guix to thwa=
rt 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=E2=80=99t go undetected for long.

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

> The =E2=80=9Creference state log=E2=80=9D mentioned in the blog post coul=
d help.

> It=E2=80=99s an interesting idea.  It addresses the scenario you describe=
d
> (redirecting users to a different branch) but it doesn=E2=80=99t address =
the
> more general indefinite freeze attack. =20

I see =E2=80=98redirecting users to a branch they shouldn't use=E2=80=99 as=
 a separate attack
from the =E2=80=98indefinite freeze attack=E2=80=99. My proposed attack met=
hod was a mixture
of both.

The general =E2=80=98indefinite freeze attack=E2=80=99 doesn't seem solvabl=
e, but the more
specific related attack =E2=80=98redirecting users to a branch they shouldn=
't
use=E2=80=99 _is_ solvable. Not being able to solve the complete problem sh=
ouldn't
stop =E2=80=98us=E2=80=99 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 =E2=80=98indefinite freeze attack=E2=80=
=99 in its full
generality, but this specific case seems solvable.

> Something like the =E2=80=9Creference state log=E2=80=9D would
> help address the general case.
>
> Thoughts?

I need to take a look at what this =E2=80=98reference state log=E2=80=99 is=
.

Greetings,
Maxime.

--=-omHmrGd5rOsqRKm47qdS
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYJOmkhccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7kc1AQDR43GdHm2zQK2HNbOBsVr+gZzB
9cmtyFxffCzQWFy00QD+MlneJBnlYn8MLZeVWGOEPCker3aFhGXjm/K6960TxAI=
=cN8N
-----END PGP SIGNATURE-----

--=-omHmrGd5rOsqRKm47qdS--

Last modified: Thu, 6 May 2021 08:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.