unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Maxime Devos <maximedevos@telenet.be>
Cc: 48146@debbugs.gnu.org
Subject: bug#48146: Getting diverted to non-updated branches: a limitation of the authentication mechanism?
Date: Wed, 05 May 2021 22:34:13 +0200	[thread overview]
Message-ID: <874kfgj4xm.fsf@gnu.org> (raw)
In-Reply-To: <b3c137f53eb256d43267e2358874bd25e4686e32.camel@telenet.be> (Maxime Devos's message of "Sat, 01 May 2021 23:40:01 +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.

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.

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.  The “reference state log” 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 
>
>      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@gnu.org.
>
>      It is safe to simply run "guix pull" again later.
>  16. If there is a path from A to B that _does_ have a 
>
>      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’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’m not sure it’s worth focusing
on this special case.  Something like the “reference state log” would
help address the general case.

Thoughts?

Thanks for thinking through it!

Ludo’.




  parent reply	other threads:[~2021-05-05 20:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-01 21:40 Maxime Devos
2021-05-02  4:09 ` Leo Famulari
2021-05-05 20:34 ` Ludovic Courtès [this message]
2021-05-06  8:19   ` Maxime Devos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874kfgj4xm.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=48146@debbugs.gnu.org \
    --cc=maximedevos@telenet.be \
    --subject='Re: bug#48146: Getting diverted to non-updated branches: a limitation of the authentication mechanism?' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

unofficial mirror of bug-guix@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-bugs/0 guix-bugs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-bugs guix-bugs/ https://yhetil.org/guix-bugs \
		bug-guix@gnu.org
	public-inbox-index guix-bugs

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.bugs
	nntp://news.gmane.io/gmane.comp.gnu.guix.bugs


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git