Hacker News Reader

Comment by raesene9 | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

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.

> 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.

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

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.

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

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...

Seems like this actually happened on github: https://twitter.com/_staaldraad/status/1001542421161930752

> 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.

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.

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.

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?

Reply on news.ycombinator.com