Russ Allbery <r...@debian.org> writes: >> Can this be substantiated? Using SHA1CD in Git does not necessarily >> mean someone cannot manually create a Git repository with a colliding >> git commit somewhere in the history that gets accepted by git, and >> allows someone to replace actual file contents. That may be the case, >> but I haven't seen any detailed analysis answering that. > > This was a really interesting point that I didn't catch. Thank you! Let > me try to rephrase this in the form of an attack and see if this captures > what you were getting at. > > The attack: Using a pre-SHA-1DC version of Git, construct a benign and > malicious pair of Git trees that diverge at some point by abusing the hash > of an object vulnerable to SHAttered.
Right, and that this happened at some point in the past rather than on the git tag commit id. This git repository could be the upstream or the debian git repository. > Push the benign tree to Salsa, relying on Salsa not reverifying the > hashes of new objects with a hardened hash, or alternately have > already planted the benign tree in a Git repository imported into > Salsa before SHA-1DC was in use. Get that tree signed by a sponsor, > again relying on the sponsor's git client not revalidating object > hashes, and then follow the same attack pattern in either "Moving the > tag" or "Replacing the upstream tree." Rely on the tag2upload server > not reverifying the hashes of the Git tree when it pulls it to > construct the signed source package. > > In essence, this attack exploits the fact that Git is lazy about > performing hashes and usually only does so when it has to. I'm not sure > this assumption is correct for Salsa in particular, but it's at least > plausible. The trees used in this attack would fail git fsck, because the > critical object would hash to a different value using SHA-1DC than it does > with SHA-1, but it's not clear that git fsck is called at any of the > points that would detect this attack. > > I believe this attack would be prevented by setting transfer.fsckObjects > to true in the Git configuration of the tag2upload worker and failing the > operation if it detects anything. (Or, equivalently, calling git fsck > after git clone and failing on any detected problems.) I believe this > forces recomputation of the hashes of all received objects. The object > used in this attack would fail that hash recomputation because the > tag2upload server would use a version of Git that uses SHA-1DC. The cost > is a performance penalty on git clone, which would be trivial for most > repositories but which might be noticable for particularly large Git > trees. > > My personal opinion is that always setting transfer.fsckObjects to true is > good practice anyway to catch more banal problems such as disk corruption > and memory bit flips, so while I'm not sure I would bother just for this > attack, it might be a good idea on general principles. I have had that settings in my .gitconfig for several years, and the number of git repositories that fail to clone with it is not negligible. I encourage people to enable it and experiment for themselves. Try https://git.savannah.gnu.org/git/coreutils.git for example. I hack around it by adding a 'fclone' alias, and I still need to use it once in a while. [transfer] fsckObjects = true [alias] fclone = clone -c "fetch.fsckObjects=false" Maybe the number of repositories on Salsa with this problem is low, but isn't the tag2upload design vulnerable to upstream git repositories having this problem too? In the part of tag2upload that re-generate the *.orig.tar.gz file. Maybe I'm missing how that is supposed to work, relying on debian/watch does not strongly/uniquely identify a release artifact. Many distributions store SHA256 hashes of the expected upstream release tarball, and this is a good practice that Debian doesn't support to my knowledge. /Simon
signature.asc
Description: PGP signature
