Re: Potential security issue with make authenticate and mitigation

[Ludovic Courtès]

Hi!

John Kehayias  skribis:

> In 2020, the "guix git authenticate" tool was added in order to secure
> updates (1). This protection is still intact! The tool also had the
> secondary effect of protecting developers against malicious commits
> while we are developing. In fact, the manual currently recommends that
> all developers run "make authenticate" after every pull for this
> purpose (2).
>
> Unfortunately, it turns out that "make authenticate" can itself be
> used as an attack vector. The core of the problem is that "make
> authenticate" uses the Makefile before the commits have been
> authenticated, allowing an attacker to replace the Makefile with a
> malicious version. The attacker would need the ability to inject the
> malicious commit into the data you pull: for example, by compromising
> the Savannah server or poisoning a DNS cache. The attached report
> contains full details and a proof of concept.

Yes, that is a problem.  (Initially, the ‘authenticate’ target would
even run ‘guix git authenticate’ from the very repo we want to
authenticate, because ‘guix git authenticate’ wasn’t widespread yet (see
commit 1dba0b4557e67b32e64d98c807fb376604e5d19b).  And actually the
target predates ‘guix git authenticate’ (see
1e43ab2c032834e43a43eb4c27d6a50bf66b86ba).)

Good news is that starting from yesterday, ‘guix git authenticate’
addresses several usability issues; quoth news.scm:

  Usage of the @command{guix git authenticate} command has been
  simplified.  The command is useful to channel authors and to developers
  willing to validate the provenance of their code.

  On your first use, @command{guix git authenticate} will now record the commit
  and signer (the @dfn{introduction}) in the @file{.git/config} file of your
  repository so that you don't have to pass them on the command line in
  subsequent runs.  It will also install pre-push and post-merge hooks,
  unless preexisting hooks are found.

(See .)

So now we can remove the ‘authenticate’ target and update our doc to
recommend running plain ‘guix git authenticate’.

Thoughts?

Ludo’.

Potential security issue with make authenticate and mitigation

[John Kehayias]

Hi Guix-ers,

Please see the below message (and attached report for further details)
of a potential security issue and mitigation in Guix, from Skyler
Ferris. The very short version: 'make authenticate' is a potential
attack vector, which can be mitigated by using 'guix git authenticate'
in a development workflow.

This was raised to guix-security some months ago, but unfortunately
went through various stalls and got lost for a bit. My apologies to
Skyler and thanks for their patience. At least one other person on
guix-security also recommended we open this up for public comment,
which I agree would be good as we can discuss the potential workflow
and documentation changes quickly and transparently.

Please also see the proposed changes to make 'guix git authenticate'
easier to use, which could also help make easier to use in the Guix
workflow: 

(As an aside, some new members for guix-security would be helpful. I'm
happy to continue but will be away for about a month soon.)

>From Skyler, lightly edited for formatting:

In 2020, the "guix git authenticate" tool was added in order to secure
updates (1). This protection is still intact! The tool also had the
secondary effect of protecting developers against malicious commits
while we are developing. In fact, the manual currently recommends that
all developers run "make authenticate" after every pull for this
purpose (2).

Unfortunately, it turns out that "make authenticate" can itself be
used as an attack vector. The core of the problem is that "make
authenticate" uses the Makefile before the commits have been
authenticated, allowing an attacker to replace the Makefile with a
malicious version. The attacker would need the ability to inject the
malicious commit into the data you pull: for example, by compromising
the Savannah server or poisoning a DNS cache. The attached report
contains full details and a proof of concept.

Fortunately, preventing this problem is fairly straightforward:
instead of running "make authenticate", run "guix git authenticate"
manually. This will detect the malicious commit before the Makefile is
used, alerting you to the problem. As a first step towards a long-term
solution we can stop recommending the use of "make authenticate" in
the manual. We would like to remove the "authenticate" target entirely
because it is easy to misuse. However, this could break existing
workflows. Hopefully this is trivial to solve by running the tool
manually as mentioned above but maybe there are some situations we
have not considered - let us know! We are also aware that the
post-push hook installed by Guix runs "make authenticate". However,
this is only done as a reminder to the developer to avoid breaking
"guix pull"; it is not done for the developer's security. The
post-push hook can be changed to use "guix git authenticate" instead
of "make authenticate" in the same set of patches to avoid breaking
anything.

(1) 

(2) 

Thanks everyone!
John

(Apologies is this went through to some people, but I only realized
days later it wasn't sent to the correct guix-devel address.)


security-report.md
Description: Binary data