#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:5 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. I also see that git outputs the tag object when we run `git tag -v [tag]`. So we could check that the tag is the right tag in rbm. I opened #30480 to do that. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30479#comment:6> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs