Thread

Git 3.0's upcoming SHA-256 default will be a costly mistake

570 points · 536 comments · chmaynard

kpcyrd · 1790876562 · focus · HN ↗
This article is full of mistakes and misleading claims:
1) It's claiming SHA1 insecurity is theoretical, while SHAttered from 2017 was specifically a pratical proof of concept. The only reason Git wasn't affected, is because they didn't bother bruteforcing a git-blob prefix.
2) It's claiming collision attacks don't matter, only second-preimage attacks do. This is incorrect, collision attacks are enough for code-smuggling problems, when two repositories are on the same git commit (verified by the full commit hash), yet contain different code in their git checkout.
3) The Linus quote "The real security is in distribution" is arguing that "git's content-addressed system should not be used to address content". It's arguing that, in case of curl|sh, you shouldn't use a sha256sum-gate to pin the content to something you've reviewed, you should instead ensure curl is fetching from an https server.
1. schacon · 1790877053 · focus · HN ↗
  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.
  2) I specifically argue that even if both attacks were practical and cheap, it's still not the problem we should be focusing on.
  3) Have you read this email (that I linked to)? It is almost the same general message (20 years ago) that this blog post is. It literally goes though a theoretical object replacement attack and how dumb this scenario is and so SHA-1 is fine.
  <a href="https://lore.kernel.org/git/Pine.LNX.4.58.0504291221250.18901@ppc970.osdl.org/" rel="nofollow">https://lore.kernel.org/git/Pine.LNX.4.58.0504291221250.1890...
  1. bawolff · 1790880417 · focus · HN ↗
    > 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?
    AlfeG · 1790883247 · focus · HN ↗
    Even if it costs zero to create. How do You force people to pull from Your repo?
    axus · 1790885545 · focus · HN ↗
    Hack into the system holding a trusted repository, and swap in your variant with same signature?
    jurgenburgen · 1790917510 · focus · HN ↗
    That variant would likely not even compile?
    aarmot · 1790919070 · focus · HN ↗
    You can put your entropy in comments and strings
    kstrauser · 1790923171 · focus · HN ↗
    And commit messages.
    JoshTriplett · 1790926176 · focus · HN ↗
    And the date. And hidden headers in the commit that you'd only see if you use `--pretty=raw`.
    patmorgan23 · 1790898234 · focus · HN ↗
    Social engineering?
    maccam94 · 1790901093 · focus · HN ↗
    DNS cache poisoning?
    kpcyrd · 1790910318 · focus · HN ↗
    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.
    theParadox42 · 1790920848 · focus · HN ↗
    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.
    kstrauser · 1790923156 · focus · HN ↗
    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.
    kpcyrd · 1791072880 · focus · HN ↗
    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.
    odo1242 · 1790925341 · focus · HN ↗
    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)
    Dylan16807 · 1790926676 · focus · HN ↗
    You also have to trick the code git added to detect and block shattered-style attacks.
    Still, eliminating the risk is a good idea.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.