4 ms·

Sounds like it could be devastating for shared git hosting like github, bitbucket, gitlab, and for anyone just mirroring repos.

• raesene9 8y ago
  Unless I'm reading it wrong the attacker still has to have a repo. under their control, then get the victim to clone the repo. I'm not saying it's trivial , but more that people execute code from GH and similar alll the time without reading/evaluating , and this won't do any worse than that.
  • 0x0 8y ago
    Let's say you sign up for a free account on a shared git-whatever.example.com and set it up to auto-mirror a malicious repo you host elsewhere. If git-whatever.example.com(1) had implemented its mirror feature on top of regular git, boom and you might get shell access on their server and full access to any and all private repos stored on the same service. (1) could be any shared service like gitlab.com, github.com, bitbucket.org, etc
    • raesene9 8y ago
      oh yeah, cool :) I was thinking about the issue from the perspective of an ordinary user of git, not of services that consume git repo's from other places. I guess this will make some bug bounties for researchers who can find services that haven't patched quickly...
      • 0x0 8y ago
        Seems like this actually happened on github: https://twitter.com/_staaldraad/status/1001542421161930752 https://twitter.com/_staaldraad/status/1001542421161930752
  • xorcist 8y ago
    > then get the victim to clone the repo Recursively. I don't think I've ever done that, even on the few places which have used submodules, but I guess some people do.
• ethomson 8y ago
  Part of this bugfix includes changes to "git fsck" to reject these problematic repositories. Git hosting sites like GitHub and Visual Studio Team Services are actively blocking these repositories today to prevent being used as vectors for propagating this vulnerability.