[tor-bugs] #30479 [Applications/Tor Browser]: Move away from using signed git tags to avoid rollback attacks?

[Tor Bug Tracker & Wiki]

#30479: Move away from using signed git tags to avoid rollback attacks?
--------------------------------------+--------------------------
 Reporter:  gk                        |          Owner:  tbb-team
     Type:  defect                    |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  tbb-rbm                   |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------
Description changed by gk:

Old description:

> When using git repos we try to build from signed git tags whenever
> possible and make sure we check the signature being valid. It turns out,
> though, that keys might expire at some point making the signature
> verification fail from that point on. This is unfortunate for some of
> reasons: it might break building current Tor Browser versions (see
> #19737) and it might break verifying older releases which would be nice
> to have to be able to verify later on that everything went right.
>
> We chose in #19737 to ignore expired keys in the sense that we treat a
> signature as valid as long as the verification succeeds (modulo the
> expiration problem). Now it has been argued that this could lead to
> rollback attacks in the sense that an attacker could modify a git repo in
> a way that the tag we want to use point to older code while still
> satisfying all of the git tag signing consttraints we have.
>
> However, thinking a bit more the expiration problem is actually
> orthogonal as this could even happen with a properly signed tag which
> does not suffer from a signature done with an outdated key, but which is
> still not the current version. That means assuming you have three tags
> t1, t2, and t3 and t1 has a sig which is expired while t2 and t3 not, but
> only t3 contains the critical fix then with a git attacker in question it
> does not make a difference whether we fix the expiration date problem as
> they could easily make us use t1 *or* t2.
>
> For fixing the expiration date problem there are some proposals with
> different trade-offs:
>
> 1) We could use signing keys that do not expire (see:
> https://blog.invisiblethings.org/keys/). If at all this is only helpful
> for our own keys but we use other project's git tags as well which might
> use expired signing keys.
>
> 2) We could use Peter Todd's OpenTimestamps tool
> (https://petertodd.org/2016/opentimestamps-git-integration). That again
> might seem useful but we have the problem again that we use other
> project's keys which might not have those timestamps.
>
> 3) Even if we solved 1) and 2) magically we'd still have the problem
> above that an attacker can point to either t1 or t2. So a different
> approach would be to point to (signed) commits directly to avoid the
> problem that (signed) tags could point to anything.
>
> So, should we switch to pinning cpmmits from now on? Or is there even a
> better solution available?
>
> (Thanks to kevun and arma for input)

New description:

 When using git repos we try to build from signed git tags whenever
 possible and make sure we check the signature being valid. It turns out,
 though, that keys might expire at some point making the signature
 verification fail from that point on. This is unfortunate for some
 reasons: it might break building current Tor Browser versions (see #19737)
 and it might break verifying older releases which would be nice to have to
 be able to verify later on that everything went right.

 In #19737 we chose to ignore expired keys in the sense that we treat a
 signature as valid as long as the verification succeeds (modulo the
 expiration problem). Now, it has been argued that this could lead to
 rollback attacks in the sense that an attacker could modify a git repo in
 a way that the tag we want to use points to older code while still
 satisfying all of the git tag signing constraints we have.

 However, thinking a bit more the expiration problem is actually orthogonal
 as this could even happen with a properly signed tag, which does not
 suffer from a signature done with a key that is expired now, but which is
 still not the current version. That means: assuming you have three tags
 t1, t2, and t3 and t1 has a signature which is expired while t2 and t3
 don't, but only t3 contains the critical fix, then with a git attacker in
 question it does not make a difference whether we fix the expiration date
 problem as they could easily make us use t1 *or* t2.

 For fixing the expiration date problem there are some proposals with
 different trade-offs:

 1) We could use signing keys that do not expire (see:
 https://blog.invisiblethings.org/keys/). If at all this is only helpful
 for our own keys but we use other project's git tags as well which might
 use expired signing keys.

 2) We could use Peter Todd's OpenTimestamps tool
 (https://petertodd.org/2016/opentimestamps-git-integration). That again
 might seem useful but we have the problem again that we use other
 project's keys which might not have those timestamps.

 3) Even if we solved 1) and 2) magically we'd still have the problem above
 that an attacker can point to either t1 or t2. So a different approach
 would be to point to (signed) commits directly to avoid the problem that
 (signed) tags could point to anything.

 So, should we switch to pinning commits from now on? Or is there even a
 better solution available?

 (Thanks to kevun and arma for input)

--

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30479#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online