Hacker News Reader

Comment by lamontcg | Hacker News Reader

Yeah what is the attack here?

If you don't have permissions to my repo that already limits the scope of attackers to people who already have repo access. At that points there's tons of abuse avenues open that are simpler.

If someone could fork a repo, submit a pull request and push a sha for an already existing commit and that would get merged and accepted (but not show up in the PR on github) well that would certainly be troubling, but at that point I'm well past my understanding of git internals as to how plausible that kind of attack would be...

View on HN

Repo access doens't stop people from injecting code into your repository. A pull request actually puts objects into your repo, but under a different ref than heads and tags.

1. Go to github, do a git clone 'repo' --mirror 2. cd to the bare repo.git and do a git show-ref and you will see all the pull requests in that repo. If any of those pull requests contained a duplicate hash, then in theory they would be colliding with your existing objects. But since git falls back to whatever was there first, I think it would be very challenging indeed to subvert a repo. You'd essentially have to find somebody who's forked a repo with the intention of submitting a PR, say, on a long running feature branch.

You could then submit your PR based off hashes in their repo before they do, which would probably mean your colliding object would get preference.

Its pretty far fetched, but the vector is non-zero.

It's easier than that. Someone could create a benign patch and a malicious patch that collides the hash. But what could they do with that?

For example, let's say it goes (letter##number represents the hashes):

State 1:

Real repo: R3 -> R2 -> R1 -> R0 (note: R3 is the head)

Benign PR: B1 -> B0 -> R1

Malicious PR: M1 -> M0 -> R1 (note: M0 = B0, but the contents are different)

State 2, after merging Benign PR:

Real repo: R4 -> R3 -> R2 -> R1 -> R0, R4 -> B1 -> B0 -> R1

If Malicious PR was merged now, Git would, I imagine, just believe that M1 is a commit that branched off of B0, since that's where the "pointer" is at.

So, yeah, what would this actually accomplish?

If the sha matched an existing one, would it be merged as part of the changeset, or just ignored?

If a sha matches, git won't fetch the object because it already has it.

Reply on news.ycombinator.com