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?
    schacon · 1790881034 · focus · 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.
    bawolff · 1790886258 · focus · HN ↗
    You still mentioned the (1) part, which is what i object to. I agree its not fatal to your argument.
    doc_ick · 1790950132 · focus · HN ↗
    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.
    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.
  2. kpcyrd · 1790885757 · focus · HN ↗
    Basing your cryptographic advice on a 20 year old opinion-piece from somebody with no background in cryptography is not the flex you think it is.
    wavemode · 1790897107 · focus · HN ↗
    Appealing to lack-of-authority without actually explaining in what way his argument is wrong is significantly worse.
    PunchyHamster · 1790898607 · focus · HN ↗
    But the Linus piece is sound
    ... for Linux
    ... and developers working for it constantly
    the attack wouldn't work. Joe Schmoe? It's worse than just "being compromised"
    You have repo of dependency locally, let's assume you downloaded good copy, the commits get compromised, you're safe.... right ?
    Nope, if there is build server along the way and ESPECIALLY if it practices building from clean state every time, the build might be infected while your local copy is clean, giving no chance to notice it, unless your entire chain including local builds are reproductible AND you actually check it
    throwawayffffas · 1790907006 · focus · HN ↗
    It's not cryptographic advice from an opinion piece, it's a statement about intent from the creator of the software in question.
  3. bityard · 1790909767 · focus · HN ↗
    In agreement that this is good old fashioned cargo-cult security theatre, but tom7 also coined a more catchy phrase for this, he calls it "toxic max-security." <a href="http://tom7.org/httpv/httpv.pdf" rel="nofollow">http://tom7.org/httpv/httpv.pdf
    ozim · 1790922095 · focus · HN ↗
    Oh I call those people „TLS antivaxxers”.
    Conveniently Tom didn’t mention anything about Edward Snowden and what he published. That was basically start of TLS everywhere.
    Then he didn’t mention ISP idiots that were actually injecting ads to cute websites like Tom’s. I hope Tom likes when his website is used by ISP to make money on ads he doesn’t have any control over.
    Then he goes on to criticize certificate transparency, but it works. Companies got kicked out from trusted root program because they were doing stupid stuff like making certs they shouldn’t.
    Let’s not forget glorious state of Kazakhstan where without TLS they would just listen to all traffic - well with TLS they were trying to pull MITM but were uncovered and got their stuff removed by TLS ecosystem.
    voidnap · 1790924174 · focus · HN ↗
    If I recall, tom7 was at odds with chrome throwing up a warning at users trying to visit his website because he didn't support TLS on it. He wasn't against TLS. Calling them a TLS antivaxxer is not accurate.
    ozim · 1790924789 · focus · HN ↗
    I just read the pdf that parent poster included.
    While he does indeed have extensive knowledge of TLS/SSL. He still completely side steps points I wrote about and exaggerated many minor inconveniences. While PDF seems quite up to date it also picks on stuff that is not there anymore like green padlocks.
    kbolino · 1790945068 · focus · HN ↗
    I don't particularly like the terminology but, still, the attitude that TLS is just for "sensitive" websites, actions, or data is quite wrong. Even if you don't care about surveillance or ISP ad injection, you should care about infrastructure compromises and exploit injection. It sounds exotic and high effort but it's not. Unless you're personally auditing the coffee shop, airport, library, hotel, etc. Wi-Fi hardware and network before you connect, it could affect you easily. It's not even a choice that reasonably belongs in the hands of website owners, because they don't control all the paths from users back to them. And even residential and municipal ISP networks can get compromised, too, along with data centers and everything in between.
    ozim · 1790952904 · focus · HN ↗
    Yeah I kind of forgot exploit injection in the spur of the moment as of course I rushed to correct "someone on the internet".
    ISP injecting ads is like annoying but if someone knows as much as Tom about TLS and totally skips rouge "airport wi-fi" can use his website to own someones else device that is the argument I should use for calling him or anyone else names on the internet.
    I guess Kazakhstan example kind of covers it, because I do believe they would definetly deliver malicious payloads to dissidents.
    kbolino · 1790953260 · focus · HN ↗
    There's a lot of lingering "SSL is just for your bank" sentiment out there. There are other ways to achieve integrity protection than using TLS, and there are even ways to use TLS without WebPKI, but nobody is putting any effort into any of them, and so TLS+WebPKI is the solution, and no website is exempt, because it is fundamentally an infrastructure problem.
    ForHackernews · 1790937960 · focus · HN ↗
    > I hope Tom likes when his website is used by ISP to make money on ads he doesn’t have any control over.
    You mean like how Google makes money showing ads against your content that you don't control? You mean how basically every ad network works?
    yrxuthst · 1790944447 · focus · HN ↗
    No, Google shows ads on their own domain. You would have to opt in by adding the script, for their ads to show up on your domain like the ISP ads do.
    ForHackernews · 1790979000 · focus · HN ↗
    Did you opt-in to having your content shown in "previews" and Gemini "instant answers" along with Google ads?
    I could just as easily argue that by paying my ISP and signing up to their T&Cs, I've opted in to seeing their ads, not the ads from some random website.
    ozim · 1790952446 · focus · HN ↗
    What ISPs were doing they were injecting ads and you had no way of knowing it happens unless some visitor was annoyed enough to make you aware by sending you a screenshot.
    With Google you have to make an agreement and put piece of code in your website willingly and then you get minimal cut but still, that is totally your choice.
  4. onion2k · 1790922602 · focus · HN ↗
    I say it's impractical to exploit, which I think everyone agrees with.
    Impractical for an individual, definitely. For a large org, maybe, but if the payoff was big enough? For a nation state level actor intent on doing something, absolutely not.
    The go-to example is Stuxnet. Some countries wanted to attack Iran's nuclear enrichment programme, so they spent 5 years developing a worm that used multiple zero day exploits to attack a specific controller in a specific model of gas centrifuge. Could Mythos write Stuxnet? Unlikely, but a knowledgable team with access to it could probably write it in a lot less than 5 years.
    'impractical' has very different values for different groups.
    hypfer · 1790925682 · focus · HN ↗
    Okay, fair enough. But does that make sense as a default setting then?
    I can see that some things might have a risk profile that might possibly make all this costs still worth it, but does it make sense to have these unicorn projects effectively blow up 20 years of ecosystem?
    Shouldn't the extra cost of doing something out of the ordinary be carried by whoever does something out of the ordinary?
    This feels like a bridge to be crossed when one gets there (if at all).
    __
    FWIW, we actually do have a choice here. No one is forcing the industry at large to adopt an unpatched git 3.0 binary built from a source that makes that a default.
    This should be a trivial overlay to carry around with effectively no downsides. So convincing whoever is steering that ship doesn't necessarily matter, as long as enough sane pragmatics agree on how defaults should actually be.
    plopilop · 1790929973 · focus · HN ↗
    We are migrating all of PKI to the more costly and less efficient postquantum cryptography, even though nobody will reasonably use a quantum computer to snoop on your home IoT daily reports. I mean, I assume that what you are doing on your free time is not worth governmental attention.
    The rationale of mass migration is that if you don't impose it, nobody migrates. This has notably been the case with famously insecure SSL parameters (512 bits RSA keys, PKCSv1.5...). And many companies may believe they are not critical, which might be true until it is not.
    Case in point: you manufacture walkie talkies and suddenly your products have bombs inside. Or you maintain a compression library for free and suddenly you are shipping a backdoor to all Linux products.
    hypfer · 1790931785 · focus · HN ↗
    My reply did not exhibit a lack of understanding of this mechanism.
    It instead questioned to which degree execution of them is reasonable in a world that does not contain infinite resources.
    Everything is a trade-off. Not all of them make sense.
    plopilop · 1790945102 · focus · HN ↗
    Sure, but here I guess the main idea is that everything is linked, especially how libraries package managers work nowadays.
    In order to compromise the big player, you only have to compromise the weakest link in its supply chain. In effect that means that leaving the migration optional is as useless as doing nothing.
    hypfer · 1790947936 · focus · HN ↗
    Let me put it differently:
    It is not of my concern to live in ways that are harder for me, just so that big tech can have it easier.
    plopilop · 1790951184 · focus · HN ↗
    Big tech being compromised will also make your life harder. The opposition small/big players is not as clear cut as one would like.
    hypfer · 1790955839 · focus · HN ↗
    Sure, buddy. Let's just not question anything at all. Move along, don't cause friction.
    Jesus man.
    doc_ick · 1790974630 · focus · HN ↗
    It does make sense to set sha256 as the default. I would like even strong to future proof things a bit, but sha256 is a good upgrade.
    Dylan16807 · 1790987787 · focus · HN ↗
    Yeah that argument you completely imagined and nobody implied is ridiculous!
    LeFantome · 1790955014 · focus · HN ↗
    This is the whole concept of Defense in Depth.
    Iolaum · 1790932107 · focus · HN ↗
    > nobody will reasonably use a quantum computer to snoop on your home IoT daily reports
    Feel free to tell that to journalists investigating corruption ...
    afavour · 1790941949 · focus · HN ↗
    Literally the next sentence:
    > I assume that what you are doing on your free time is not worth governmental attention.
    Definitely does not apply to journalists investigating corruption.
    phkahler · 1790952510 · focus · HN ↗
    >> > I assume that what you are doing on your free time is not worth governmental attention.
    > Definitely does not apply to journalists investigating corruption.
    And that bring to mind another aspect - When strong security is not the default, anyone using it looks suspicious in some eyes.
    johnisgood · 1790934563 · focus · HN ↗
    > I assume that what you are doing on your free time is not worth governmental attention.
    <a href="https://www.change.org/p/stop-the-chat-control-european-regulation" rel="nofollow">https://www.change.org/p/stop-the-chat-control-european-regu... is worth a read, IMO!
    As for "nobody will reasonably use a quantum computer to snoop on your home IoT daily reports", they already have access to your data one way or another, so really no need for a quantum computer. :P
    dgellow · 1790942725 · focus · HN ↗
    I don’t understand your comparison with walkie talkies. What are you trying to highlight here? In the case of the pager attack in Lebanon the devices were booby-trapped. Are you trying to say that the device designers should have somehow done something about it? I cannot really make sense of it
    plopilop · 1790944409 · focus · HN ↗
    My point is that the business of pagers is rarely seen as something likely to be booby trapped by a nation state. Yet in the context of Lebanon it happened.
    I don't remember where the compromise happened (factory, distribution, sell point), but very clearly at least one of them did not expect to be a critical asset in the Israel - Lebanon war.
    da_chicken · 1790944163 · focus · HN ↗
    Exactly. Reasonably speaking, nobody tries to pierce encryption at all, ever. That doesn't mean we should stick with 3DES. Reasonably speaking, nobody will try to break in to your house at all, ever. That doesn't mean you shouldn't lock your door. Security is already about protecting against infrequent events.
    > And many companies may believe they are not critical, which might be true until it is not.
    I'm at a K-12 public school. That shouldn't be on the front lines of a war with Iran, but, in cybersecurity terms, we are. If you disrupt a school district, you disrupt one of the largest employers in the area. You also disrupt the largest childcare facility in the area. The amount of economic damage you could inflict on a community by disrupting the public school system is pretty extreme compared to the amount of funding provided to protect it.
    throwaway7356 · 1790949425 · focus · HN ↗
    > I mean, I assume that what you are doing on your free time is not worth governmental attention.
    > Or you maintain a compression library for free and suddenly you are shipping a backdoor to all Linux products.
    You already showed yourself that your naive assumption is wrong for a relevant group that uses Git.
    plopilop · 1790951290 · focus · HN ↗
    Yes, that's exactly the point I'm trying to make?
    Assets are non critical until they become critical.
    e40 · 1790944817 · focus · HN ↗
    > blow up 20 years of ecosystem?
    What does that mean?
    da_chicken · 1790925713 · focus · HN ↗
    Yes, and in the days of major supply chain attacks and state-sponsored near catastrophes like xz, "it's probably good enough" starts to look incredibly naive.
    Linus's "what matters is distribution" comment also doesn't make sense when merge effectively is distribute. Which, again, is the reality of supply chain.
    m000 · 1790932130 · focus · HN ↗
    This is an apples to oranges comparison.
    Stuxnet is essentially "boutique malware". You can buy it/have it built with enough money/resources.
    Weaponizing a cryptographic algorithm with some theoretical vulnerabilities (but no by-design backdoor built-in) is a totally different game. And TFA is right that it's a dumb endeavour. You can probably "stuxnet" your way in for much cheaper.
    thereforegrin · 1791012146 · focus · HN ↗
    the comment is highlighting the fact that git's use of sub-par cryptography makes "boutique supply-chain" attack easier to pull off.
    michaelt · 1790934700 · focus · HN ↗
    > Impractical for an individual, definitely. For a large org, maybe, but if the payoff was big enough? For a nation state level actor intent on doing something, absolutely not.
    In all the years since 2017, with all the orgs having huge GPU-filled data centers (and an interest in software security) has anyone demonstrated a real git collision?
    Some systems have other properties that mitigate or prevent second preimage attacks - for example when you get an SSL certificate, CAs randomise the serial number. So an attacker can’t choose the checksum of the data the CA signs. Perhaps something in the design of git is similar?
    tosapple · 1790948195 · focus · HN ↗
    'randomize' is possibly the wrong word, it could include some form of serialization/fingerprint.
    tialaramex · 1790950118 · focus · HN ↗
    No, it really is the correct word. They just pick a huge random number. There's no value in "serializing" or "fingerprinting" such a number. It has two purposes, we need it to be unique, and we need it to be random and because it's a huge number being random means it is unique so we are done.
    tosapple · 1790959938 · focus · HN ↗
    yeah i don't know as esoteric as it is it could be a referential index into a bitmask/seive for your key.
    there's a lot you can do behind the scenes with even a couple bits of... free space?
    the key should be enough of a unique id to not have to require this? see (hash). a separate linked 'randomized' unique identifier might be crazy man territory but i'm not lying... your 'weakened' key doesn't _need_ to be all zeros, just predictable eg. within a certain time frame, anything that can reduce the search space is dangerous.
    edit: it could contain an identifier for which hrng was used to produce it.
    tialaramex · 1790964903 · focus · HN ↗
    This feels like you either don't know why we require this or, perhaps even more weirdly, you do understand why we require this but you've concocted some elaborate conspiracy to justify that rather than accepting the obvious explanation.
    At some point "The world is actually ball shaped" just makes a lot more sense than the thousands of years of vast elaborate conspiracies to keep you from realising that there are Mole People whose underground civilisation is accessible from Antarctica. So in the hopes that it's the former (you just didn't understand), I shall endeavour to explain.
    The MD-series and SHA-1 and SHA-2 series of cryptographic checksums use what is called Merkle–Damgård construction which operates on fixed sized blocks of data. In this design if we can find a collision before a certain block, everything after that point will keep colliding. The converse doesn't work, there aren't suffix collisions which would work for any prefix, only prefix collisions which work for any suffix. In SHA-3 and newer hashes a "Sponge" construction is used, we just pour stuff into the sponge and only squeeze out a fixed-size hash at the end, so these "prefix" attacks would need to change the entire state of that sponge.
    An X.509 certificate's serial number is very, very early, before any of the information which can be chosen by the recipient. So by ensuring this number is entirely random we're making it impossible to construct information which results in a collision, the prefix for their input will be random so it's now impossible.
    This is a "defence in depth" strategy. The SHA-256 hashes used are believed to be fine, for the immediate future, but even if they were vulnerable to a prefix attack as we know SHA-1 is, the choice to have random serial numbers defends us anyway, the attack wouldn't work on certificates.
    tosapple · 1791004592 · focus · HN ↗
    [dead]
    schacon · 1790943217 · focus · HN ↗
    Impractical for everyone. Because if you want to do this, there are better attack vectors, even if second preimage was easy, even though it is impossible.
    qdotme · 1790955250 · focus · HN ↗
    And it’s also the question of different use cases.
    Asking to trust in an authority (while the main authority Microsoft/GitHub has is essentially figuring out enterprise sales well enough to be acquired by a company desperately needing developers after fumbling badly in the 2000s) is exactly the opposite of my stance - it is a large corporation, with heavy employee rotation, with substantial exposure to various forms of regulatory pressure and to various forms of corruption.
    Which is why the cryptography exists to prove the developer-to-consumer trust without trusting the intermediaries. Yes, I do check GPG signatures. Yes, I do include a git commit hash in the binaries I build. And surely I want to make sure that this doesn’t mutate because some unknown engineer at GitHub had a bad case of gambling debt.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.