15 votes

Progress update on Git's migration from SHA-1 to SHA-256

11 comments

  1. [10]
    reese
    Link
    Great article. Maybe this is obvious to others, but can we walk through the steps of how this attack would go down? I don't think I'm understanding this correctly because I can't figure out how to...

    Great article. Maybe this is obvious to others, but can we walk through the steps of how this attack would go down? I don't think I'm understanding this correctly because I can't figure out how to technically accomplish it. This is what I'm thinking (for the sake of understanding, I could not and have no intention of ever doing this):

    1. I gain access to a trusted maintainer's Git credentials or remotely access their laptop or something. Better yet, I'm trusted but nobody should trust me.
    2. I add an evil function to floppy.c that streams Rick Astley videos, sneakily executing it by, say, an unassuming bit-wise operation in an if statement. For the sake of argument, let's say I know that the exact combination of characters used to produce this modification will result in the same object hash as the previous.
    3. To check this, I run git diff and it reports no change—that's what I, the infamous Never-Gonna-Give-You-Up Hacker to-be, want, because that means there's an undetected collision. Right?
    4. I make another change, an expected change known by the other maintainers of the repository, in some other file, that results in a different (and again, expected) file hash.
    5. To go along with the expected change, I have some reason to mv the file with the evil change that has thus far subverted git diff, and to Git it appears that all I did was move or rename it, not change its contents—the hash for the file itself remains unchanged.
    6. I git add -A && git commit -m "lols" && git push and that's a bingo assuming that the server lazily rewrites floppy.c from local instead of simply re-mapping a reference, but I highly doubt that's the case—this is just remapping from the remote version of the file, right, since it only detects that the file moved? Uhhh... I hope that's the case.

    With a different approach where I rewrote an "unchanged" file somehow (is there a way to do that? would you have to hack the Git client itself, maybe, and hope the remote didn't notice?), then there are policies like receive.denyNonFastForwards to prevent me from doing so. Just because I'm a maintainer doesn't mean I'm administering the server (think GitHub), meaning protections are in place to prevent shit like this.

    At the end of the day I know Git well enough to use it for things I need to do, but I'm not an expert. Am I going down the "wrong" path to achieve the hypothetical outcome? Am I mistaken somewhere? I'm just finding it incredibly iffy as to how one could orchestrate this client-side without it being detected.

    It seems like the easiest thing, assuming one could produce hash collisions like that, would be to fuck with a server, change the files on it with the hash-collisioned evil files, which would appear the same to Git clients, but actually contain code being potentially deployed from the server that is not what it appears to be. People cloning the repo could notice the evil code, but those who are just pulling it wouldn't even see different files locally.

    Thoughts? Sorry for the wall of text vomit, I'm just trying to grok the feasibility.

    4 votes
    1. [3]
      Diff
      Link Parent
      If I'm understanding it right, you got it right the second time. It's not enough for a trusted user to modify their own copy, all they've done is attack themselves. You'd have to compromise the...

      If I'm understanding it right, you got it right the second time. It's not enough for a trusted user to modify their own copy, all they've done is attack themselves. You'd have to compromise the central repository where everyone pulls from and poison the well.

      6 votes
      1. [2]
        reese
        Link Parent
        Thanks, that helps clarify my understanding. Okay, then, to me, the Git maintainers are just trying to get ahead of an arguably microscopic attack surface, but one that, if somehow exploited,...

        Thanks, that helps clarify my understanding. Okay, then, to me, the Git maintainers are just trying to get ahead of an arguably microscopic attack surface, but one that, if somehow exploited, could cause serious harm for a while without anybody knowing wtf is going on.

        3 votes
        1. 9000
          Link Parent
          They address a real world example where this could have happened: Essentially, the attacker could have poisoned the server's copy of floppy.c, and since HEAD's hash would still match, no one would...

          They address a real world example where this could have happened:

          The compromise of kernel.org in 2011 created a fair amount of concern about the security of the kernel source repository. If an attacker were able to put a backdoor into the kernel code, the result could be the eventual compromise of vast numbers of deployed systems.

          Essentially, the attacker could have poisoned the server's copy of floppy.c, and since HEAD's hash would still match, no one would suspect anything. Then, any clones from kernel.org would result in the poisoned file being returned, which would slowly start to poison many people's kernel repositories. Depending on where in the code base the backdoor was inserted, it could be a long time before people find the vulnerability and trace its source.

          If this were to happen on the scale of GitHub, there would be madness (though, Linux is infrastructure-critical too). They could selectively poison individual projects, or even individual developer's repositories, without any major red flags.

          3 votes
    2. Weldawadyathink
      Link Parent
      Let me preface this by stating that I can use git as a user, but I do not know its inner workings. I can see another attack vector. First perform a man in the middle attack between the target and...

      Let me preface this by stating that I can use git as a user, but I do not know its inner workings.

      I can see another attack vector. First perform a man in the middle attack between the target and the central git server. (I know this is not trivial, but heartbleed and other vulnerabilities exist.) When the target clones the repo to compile a new kernel for their machines, you send the collision floppy.c instead of the good one. Git won't complain, and the chance that the target individual/company will read every line of source to find the garbled and Rick rolled file is close to zero (this also means that you don't need to make the hash collision file look like normal code too). Then, when the fresh new kernel is deployed to the companies servers, we have wonderful Rick hash collisioned code built in.

      3 votes
    3. [5]
      ThatFanficGuy
      Link Parent
      That an Inglourious Basterds reference?

      that's a bingo

      That an Inglourious Basterds reference?

      1 vote
      1. [4]
        reese
        Link Parent
        It's less of a reference, and more like Inglourious Basterds has infested my lexicon. At this point it may as well be non-fiction. In a few short decades I will vehemently hold that Hitler died in...

        It's less of a reference, and more like Inglourious Basterds has infested my lexicon. At this point it may as well be non-fiction. In a few short decades I will vehemently hold that Hitler died in a movie theater while watching the premiere of Nation's Pride.

        "He didn't die in a fuckin' bunker," I will aggressively say under my breath at my niece's second wedding, making everyone around me visibly uncomfortable. And I won't be the only one confused about that—there will be so many of us—old, white, fragile fucks who talk too loud at The Cheesecake Factory. Will people continue to believe that Hitler escaped to South America? Probably not, but the same line of conspiratorial thinking that brought us that bologna will live on in the feeble minds of the future.

        (Folks, feel free to label this as malice, I know it has nothing to do with SHA-1 or Git.)

        3 votes
        1. [3]
          cfabbro
          Link Parent
          That would be what the Offtopic label is for. Malice is strictly reserved for comments that Deimos might potentially need to intervene on... think of it like the "report" function on reddit but...

          Folks, feel free to label this as malice, I know it has nothing to do with SHA-1 or Git.

          That would be what the Offtopic label is for. Malice is strictly reserved for comments that Deimos might potentially need to intervene on... think of it like the "report" function on reddit but one that goes directly to the admins instead of the community moderators.

          p.s. I realize you may have just been joking, but just in case any new users see your comment I wanted to make it clear what Malice was actually for. ;)

          1 vote
          1. [2]
            reese
            Link Parent
            Is there any plan for users to self-label Offtopic, Joke, and even Noise? Every time I post an off-topic or pseudo-humorous comment on Tildes, I know what I did.

            Is there any plan for users to self-label Offtopic, Joke, and even Noise? Every time I post an off-topic or pseudo-humorous comment on Tildes, I know what I did.

            1 vote
  2. vorotato
    Link
    "progress" Just add a file to your repo that has a sha-256 (or whatever hash) of the files in your git repo. A git extension could solve this problem trivially and it would still be backwards...

    "progress" Just add a file to your repo that has a sha-256 (or whatever hash) of the files in your git repo. A git extension could solve this problem trivially and it would still be backwards compatible. The idea that we need a breaking change to suit a small group of users is silly.

    2 votes