Getting diverted to non-updated branches: a limitation of the authentication mechanism?

  • Open
  • quality assurance status badge
Details
3 participants
  • Leo Famulari
  • Ludovic Courtès
  • Maxime Devos
Owner
unassigned
Submitted by
Maxime Devos
Severity
normal
M
M
Maxime Devos wrote on 1 May 2021 23:40
(address . bug-guix@gnu.org)
b3c137f53eb256d43267e2358874bd25e4686e32.camel@telenet.be
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 upgrades.
4. The attacker can subvert the savannah repository, but cannot forge commit
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 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.
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

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.

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.
-----BEGIN PGP SIGNATURE-----

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


L
L
Leo Famulari wrote on 2 May 2021 06:09
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 48146@debbugs.gnu.org)
YI4mDjRZGFfLEzja@jasmine.lan
On Sat, May 01, 2021 at 11:40:01PM +0200, Maxime Devos wrote:
Toggle quote (6 lines)
> 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://theupdateframework.io/(check the "specification")
L
L
Ludovic Courtès wrote on 5 May 2021 22:34
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 48146@debbugs.gnu.org)
874kfgj4xm.fsf@gnu.org
Hi Maxime,

Maxime Devos <maximedevos@telenet.be> skribis:

Toggle quote (19 lines)
> 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.

Toggle quote (31 lines)
> 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’.
M
M
Maxime Devos wrote on 6 May 2021 10:19
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 48146@debbugs.gnu.org)
d19b01f9d94c3f12fb59ae7dad88dbea25b13220.camel@telenet.be
Ludovic Courtès schreef op wo 05-05-2021 om 22:34 [+0200]:
Toggle quote (27 lines)
> 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.

That would be the ‘indefinite freeze attack’.

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 suspicious
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: Connection 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 with status 1
guix time-machine: error: Git error: failed to connect to localhost: Connection 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 with status 1
(end of excerpt)

The ‘indefinite freeze attack’ is a real attack, but not what I'm describing here.

Toggle quote (7 lines)
> 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.

‘We’ can extend the threat model and further restrict how an attacker could
target individuals or groups. If you know of easier methods to target
individuals, please tell, maybe ‘we’ can patch guix to thwart them as well.

The existence of easier attack methods shouldn't stop us from stopping the
more complicated and/or difficult attack methods.

Toggle quote (4 lines)
> 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.

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

Toggle quote (6 lines)
> The “reference state log” mentioned in the blog post could help.

> 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 see ‘redirecting users to a branch they shouldn't use’ as a separate attack
from the ‘indefinite freeze attack’. My proposed attack method was a mixture
of both.

The general ‘indefinite freeze attack’ doesn't seem solvable, but the more
specific related attack ‘redirecting users to a branch they shouldn't
use’ _is_ solvable. Not being able to solve the complete problem shouldn't
stop ‘us’ from solving parts of the problem.

Toggle quote (2 lines)
> I'm not sure it's worth focusing on this specific case.

I don't see how we could solve the ‘indefinite freeze attack’ in its full
generality, but this specific case seems solvable.

Toggle quote (5 lines)
> Something like the “reference state log” would
> help address the general case.
>
> Thoughts?

I need to take a look at what this ‘reference state log’ is.

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

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


?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 48146@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 48146
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch