From debbugs-submit-bounces@debbugs.gnu.org Thu May 06 04:19:45 2021 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 ) 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 ) 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: Subject: Re: bug#48146: Getting diverted to non-updated branches: a limitation of the authentication mechanism? From: Maxime Devos To: Ludovic =?ISO-8859-1?Q?Court=E8s?= Date: Thu, 06 May 2021 10:19:30 +0200 In-Reply-To: <874kfgj4xm.fsf@gnu.org> References: <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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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--