Hacker News Reader

Comment by bawolff | Hacker News Reader

> 1) I link to the SHAttered paper, as well as Shambles. Git projects were not affected because it is an inefficient attack vector. I say it's impractical to exploit, which I think everyone agrees with.

It seems unlikely it will stay that way forever. Typically attacks get more efficient over time as researchers find improvements, not to mention computers getting better.

In 2015 it was estimated to cost $100,000, now the estimate is down to $10,000. Where will it be in 2035?

View on HN

I specifically argue that it doesn't matter if it's $1 and base my argument and solution around that. So it's irrelevant where it is in 2035.

You still mentioned the (1) part, which is what i object to. I agree its not fatal to your argument.

So you’d rather have a weak default for everyone rather than updating it? Share some PII then, I’m sure a mod will block it.

Even if it costs zero to create. How do You force people to pull from Your repo?

The XZ incident would have been so much worse if it would have involved a collision, pushing one object variant to github.com, and one variant to git.tukaani.org.

Then you would have security researchers making conflicting claims depending on which repository they first pulled from, even though they are on the same git commit hash.

Wait maybe I’m missing something, but are you saying the temporary confusion while people realize they have different versions would be the primary downside? I feel like that’s an acceptable loss. It seems likely that the data in both commits, while one healthy and the other corrupt, will still have to be very different in order to produce the same hash. It’s not like you can reasonably find same-hash commits that just change line19 execute_hack from true to false.

The commit message is part of the hash. You could have quite a lot of entropy there which wouldn’t get much notice until the postmortem.

The XZ incident was using binary files checked into git. When you successfully collide this file, one with the trigger, one without the trigger, they get the same git blob-object hash (assuming the chosen-prefix includes the git blob-object header). Because of this, any git tree-object referring to this file is valid for either variant (no further collision needed). This tree-object can itself be part of another tree-object, which can be referred to by a commit-object. Signing this commit with ed25519+sha256 doesn't fix the fact that the tree-object underneath is ambiguous.

People assume sha1 git is cryptographically sound, and a git commit is a secure identifier to reason about source code, whether you and me like it or not.

In GitHub, fork networks are represented as one repo on disk (this is the main optimization that makes community pull requests possible at all). So you could fork a repo and then push an object with a hash collision to it to change a file in the original, in theory.

(In practice this is harder, as the article mentions, because the new forged object would have to be a valid gzipped git object of the same length. And GitHub probably knows about this type of attack and might just, for example, prevent existing objects from being overwritten)

You also have to trick the code git added to detect and block shattered-style attacks.

Still, eliminating the risk is a good idea.

Hack into the system holding a trusted repository, and swap in your variant with same signature?

That variant would likely not even compile?

You can put your entropy in comments and strings

And commit messages.

And the date. And hidden headers in the commit that you'd only see if you use `--pretty=raw`.

Social engineering?

DNS cache poisoning?

Reply on news.ycombinator.com