GNU bug report logs - #57909
Add link to 'pre-inst-env' from 'installing from git' docs

Previous Next

Full log

View this message in rfc822 format

From: Maxime Devos <maximedevos <at> telenet.be>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 57910 <at> debbugs.gnu.org, control <at> debbugs.gnu.org, 57909 <at> debbugs.gnu.org, Emma Turner <em.turner <at> tutanota.com>
Subject: [bug#57909] bug#57910: [PATCH] Add link to 'pre-inst-env' from 'installing from git' docs
Date: Sat, 24 Sep 2022 18:23:10 +0200

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

On 24-09-2022 17:58, Ludovic Courtès wrote:
> Hi,
> 
> Maxime Devos<maximedevos <at> telenet.be>  skribis:
> 
>> As such, I think we really shouldn't recommend "make authenticate"
>> (and even remove "make authenticate".  In fact, I think we should
>> remove "make authenticate" and replace the instructions with a direct
>> "guix git authenticate ...".
> “make authenticate” runs ‘guix git authenticate’ with the right
> parameters; importantly, it runs the already-installed ‘guix’, not the
> one in the build tree, so it’s safe (prepending “./pre-inst-env”
> wouldn’t be safe as you wrote).
> 
> So I’m not sure we really need changes; WDYT?

While ordinarily, it is true that "make authenticate" runs "guix git 
authenticate" (and not ./pre-inst-env guix git authenticate), an 
attacker could have modified Makefile.am to _not_ call "guix git 
authenticate", as I've explained in the paragraph above the one you quoted:

> The solution that was proposed [...].  __Even then, it remains
> insecure, as an attacker could have modified the "make authenticate",
> as explained in more detail at
> <https://logs.guix.gnu.org/guix/2022-09-14.log#172610>. 

More concretely, I've worked out a method the hypothetical attacker 
could use the fact that "Makefile.am" is used before it is authenticated 
in the message pointed to by the link I quoted:

https://logs.guix.gnu.org/guix/2022-09-14.log#172610 :

<maximed>civodul: Currently, it's like verifying the authenticity of a 
gnupg tarball, by extracting the gnupg tarball, compiling it, and 
running the freshly compiled gnupg tarball.
<antipode>Translated to Guix:
<antipode>(1) You run "git pull" (2) an attacker has intercepted the 
network connection and modified Makefile.am's authenticate target to 
always 'succeed'. Additionally, the attacker inserts some malicious code 
somewhere (e.g. some code in Makefile.am to upload your GnuPG keys to 
evil.com). To add some stealth, the modified Makefile.am automatically 
reverts the malicious commit. (3) You run "make authenticate" as 
recommended by the manual, and now the attacker has your private keys.

Do you see a flaw in this explanation?

Greetings,
Maxime.

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Previous Next

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