Re: [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                    |     Resolution:
 Keywords:  tbb-rbm                   |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (by boklm):

 Replying to [comment:4 gk]:
 > Replying to [comment:2 boklm]:
 > > > 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.
 > >
 > > I don't think signed tags allow rollback attacks. The data that is
 signed by gpg includes the tag itself, so if an attackers returns t2 when
 we want t3, the signature will be valid but the content of the tag will
 say t2 so git should reject it.
 >
 > Here is a PoC that works for me:
 >
 > 1) Create a new tag for, say Torbutton, like 2.1.8 and push that to our
 git repo
 > 2) An attacker replaces the contents of `.git/refs/tags/2.1.8` with
 those of `.git/refs/tags/2.1.7`
 > 3) We fetch the new tag to our build machines and start building
 > 4) The verification of "2.1.8" succeeds and git is happily using the old
 and possibly outdated 2.1.7 as 2.1.8, although we wanted to have a
 different commit for 2.1.8 (i.e. the originally tagged one).
 > 5) We ship 2.1.7 although our `torbutton` config shows `2.1.8`

 Hmm, indeed it works. I was expecting git to check that the tag is really
 the tag we want, since the tag name is included in the signed data, but it
 seems that it does not check that. So it looks like a bug in git to me.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30479#comment:5>
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