3 ms·

So to an extent, this is bad, you can be compromised by a malicious git repo, however given that most people already trust code cloned from git (or acquired fro

So to an extent, this is bad, you can be compromised by a malicious git repo, however given that most people already trust code cloned from git (or acquired from similarly untrusted sources like npm, rubygems, maven central etc) it may not change the equation that much. If you run code without trusting the author, you're likely going to have a bad time.

ethomson 8y ago
It's not that you can be compromised by running the code contained in a git repository, it's that there's a bug that allows somebody to create a git repository that will cause you - merely by (recursively) cloning the repository - to run arbitrary code that they've provided. This is, of course, unexpected. And while you should perhaps raise an eyebrow if somebody you don't know asks you to recursively clone a repository that you're not interested in - this is indeed a problem and you should upgrade your Git client.
- raesene9 8y ago
  Oh yeah I'm not saying don't upgrade, what I'm saying is that you're already cloning a repo. presumably to run the code therein. Given that running the code therein (if the owner of the repo. is malicious) will hurt you, this doesn't do too much apart from have it happen earlier on :) I guess one scenario where it could be a problem is if you were planning to clone untrusted code and read it all carefully before running it.
  - phendrenad2 8y ago
    I’d guess that only 50% of times that people git pull a repo, they eventually execute it. I know that’s the figure for me personally - I pull a lot of projects down locally so i can open them in my IDE and study how they work - never to be executed.
  - lazaroclapp 8y ago
    Suppose that you are, say, a security researcher, running purely static analysis tools on the code from every git repo that you can crawl, specifically looking for malware or common bugs without running the code (simple example: you are grep-ing for AWS keys and other secrets that should never be committed to a repo). This would be unexpected and very dangerous behavior in that setting. Sure, in theory, "unexpected and dangerous behavior" is par the course for security research and you isolate even data that you don't intend to execute if you suspect it is malicious. But, in practice, this is an easy mistake to make. As another example, consider an automatic git mirror, or whatever the internal GitHub/GitLab/Bitbucket infra might do to move repos around, without intending to execute the code.
    - mclehman 8y ago
      Thank you for posting this. I found myself mostly agreeing with the user you replied to, even though I myself am crawling and cloning a large number of git repos to do some static analysis work on them. That was a niche attack vector that I'm clearly exposed to, and somehow I still wasn't seeing it.
0x0 8y ago
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.
amenod 8y ago
This is not what this is about. This is similar to figuring out that copying a file also executes it (in some cases). While I try not to run code I don't trust, I have much more liberal point of view when it comes to cloning it. I assume others do too.
- raesene9 8y ago
  It's interesting that you say you try not to run code you don't trust. I'd be interested in hearing how you establish trust in the software you run. Assuming you're using git for cloning software code, do you include libraries that are dependencies of the code you're running in your trust calculations?
bhuga 8y ago
You're not wrong for the individual laptop case. But there's a lot of systems out there that download code, inspect a text, YAML, Dockerfile, or whatever kind of file, then sandbox it to run it. That's more or less how most CI systems work, and this vulnerability happens before the sandbox.
- TooBrokeToBeg 8y ago
  > But there's a lot of systems out there that download code, inspect a text, YAML, Dockerfile, or whatever kind of file, then sandbox it to run it. I've never seen this. It smacks of terrible practice that would not last long in a daily CI system. Once you have a good version, locking on to that version is one thing. Just randomly downloading new code versions for a daily build is impractical.

ethomson 8y ago

It's not that you can be compromised by running the code contained in a git repository, it's that there's a bug that allows somebody to create a git repository that will cause you - merely by (recursively) cloning the repository - to run arbitrary code that they've provided. This is, of course, unexpected. And while you should perhaps raise an eyebrow if somebody you don't know asks you to recursively clone a repository that you're not interested in - this is indeed a problem and you should upgrade your Git client.

raesene9 8y ago
Oh yeah I'm not saying don't upgrade, what I'm saying is that you're already cloning a repo. presumably to run the code therein. Given that running the code therein (if the owner of the repo. is malicious) will hurt you, this doesn't do too much apart from have it happen earlier on :) I guess one scenario where it could be a problem is if you were planning to clone untrusted code and read it all carefully before running it.
- phendrenad2 8y ago
  I’d guess that only 50% of times that people git pull a repo, they eventually execute it. I know that’s the figure for me personally - I pull a lot of projects down locally so i can open them in my IDE and study how they work - never to be executed.
- lazaroclapp 8y ago
  Suppose that you are, say, a security researcher, running purely static analysis tools on the code from every git repo that you can crawl, specifically looking for malware or common bugs without running the code (simple example: you are grep-ing for AWS keys and other secrets that should never be committed to a repo). This would be unexpected and very dangerous behavior in that setting. Sure, in theory, "unexpected and dangerous behavior" is par the course for security research and you isolate even data that you don't intend to execute if you suspect it is malicious. But, in practice, this is an easy mistake to make. As another example, consider an automatic git mirror, or whatever the internal GitHub/GitLab/Bitbucket infra might do to move repos around, without intending to execute the code.
  - mclehman 8y ago
    Thank you for posting this. I found myself mostly agreeing with the user you replied to, even though I myself am crawling and cloning a large number of git repos to do some static analysis work on them. That was a niche attack vector that I'm clearly exposed to, and somehow I still wasn't seeing it.

0x0 8y ago

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.

amenod 8y ago

This is not what this is about. This is similar to figuring out that copying a file also executes it (in some cases). While I try not to run code I don't trust, I have much more liberal point of view when it comes to cloning it. I assume others do too.

raesene9 8y ago
It's interesting that you say you try not to run code you don't trust. I'd be interested in hearing how you establish trust in the software you run. Assuming you're using git for cloning software code, do you include libraries that are dependencies of the code you're running in your trust calculations?

bhuga 8y ago

You're not wrong for the individual laptop case. But there's a lot of systems out there that download code, inspect a text, YAML, Dockerfile, or whatever kind of file, then sandbox it to run it. That's more or less how most CI systems work, and this vulnerability happens before the sandbox.

TooBrokeToBeg 8y ago
> But there's a lot of systems out there that download code, inspect a text, YAML, Dockerfile, or whatever kind of file, then sandbox it to run it. I've never seen this. It smacks of terrible practice that would not last long in a daily CI system. Once you have a good version, locking on to that version is one thing. Just randomly downloading new code versions for a daily build is impractical.