Re: SHA1 collisions found

On Thu, 23 Feb 2017, Joey Hess wrote:

Junio C Hamano wrote:

quoted

On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess [off-list ref] wrote:

quoted

Since we now have collisions in valid PDF files, collisions in valid git
commit and tree objects are probably able to be constructed.

That may be true, but
https://public-inbox.org/git/Pine.LNX.4.58.0504291221250.18901@ppc970.osdl.org/

That's about someone replacing an valid object in Linus's repository
with an invalid random blob they found that collides. This SHA1
break doesn't allow generating such a blob anyway. Linus is right,
that's an impractical attack.

Attacks using this SHA1 break will look something more like:

* I push a "bad" object to a repo on github I set up under a
 pseudonym.
* I publish a "good" object in a commit and convince the maintainer to
 merge it.
* I wait for the maintainer to push to github.
* I wait for github to deduplicate and hope they'll replace the good
 object with the bad one I pre-uploaded, thus silently changing the
 content of the good commit the maintainer reviewed and pushed.
* The bad object is pulled from github and deployed.
* The maintainer still has the good object. They may not notice the bad
 object is out there for a long time.

Of course, it doesn't need to involve Github, and doesn't need to
rely on internal details of their deduplication[1];
that only let me publish the bad object under a psydonym.

read that e-mail again, it covers the case where a central server gets a blob replaced in it.

tricking a maintainerinto accepting a file that contains huge amounts of binary data in it is going to be a non-trivial task, and even after you trick them into accepting one bad file, you then need to replace the file they accepted with a new one (breaking into github or assuming that github is putting both files into the same repo, both of which are fairly unlikely)

David Lang