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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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                    |   Keywords:  tbb-rbm
Actual Points:                            |  Parent ID:
       Points:                            |   Reviewer:
      Sponsor:                            |
------------------------------------------+----------------------
 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)

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs