[califield]

I was wondering who found this vulnerability. You have to click through to the Git mailing list announcement[1]:

> A big "thanks!" for bringing this issue to us goes to our friends in the Mercurial land, namely, Matt Mackall and Augie Fackler.

It'd be interesting to hear how they came across this. Matt is the leader of the Mercurial project and Augie is a Mercurial core contributor.

This doesn't seem like a high priority upgrade since GitHub now blocks the vulnerability from being pushed to their servers.

[1] http://article.gmane.org/gmane.linux.kernel/1853266

edit: Upgrade ASAP!

[tptacek]

It's a very high priority, because there are things that transparently use Git and don't host all their repositories on Github. Update ASAP.

[jzwinck]

Things which transparently use Git on Windows seem likely to bundle their own copy of Git in their installer. I don't know of specific examples, but if this happens it may be trickier for average people to stay safe. Worse, I don't know how to generate a list of such programs.

[jackmaney]

Yes. This. I work in a fairly Enterprisey company that uses git as their VCS. I'm just hoping that IT is relatively calm about this and just pushes out updates/nags people about upgrading their git client.

[califield]

Yeah, but typically you have a certain level of trust in your project dependencies. Adding a library to your project often means granting access to your system anyway (if the dependency contains executable code).

[peff]

You were and are vulnerable to malicious projects by running:

    git clone git://...
    make

or anything similar, since you are running arbitrary code out of the repository. This release fixes the problem of:

    git clone git://...
    git show

etc. Git cannot fix the "clone and run" problem, which is a social one. But it should be safe to run git commands to inspect the repository contents.

[comex]

I don't think the GP should be downvoted. What you say is exactly correct - however - I can't even think of a time I've git cloned some piece of code and not proceeded to run some code from it at some point, typically on the same machine. I download code for the purpose of using it, and while I could hypothetically inspect the entire repository for malicious code, I don't think I'm unusual in not doing that on a regular basis.

I guess maybe Docker/Vagrant/etc. users don't normally run code directly on their development machine, so it can be high priority for them. But as someone who doesn't use these tools (not a web developer), for me the vulnerability is extremely low priority.

[peff]

I think we are actually agreeing.

I think it is important to have this Git fix, because it lets people be careful if they choose. But in practice most people are _not_ careful, and will happily clone and run code without inspecting it (or pipe curl to bash!). It's almost impossible to do otherwise, as there are only so many hours in the day.

Ultimately I think we are mostly protected by the fact that this kind of attack is simply not all that common. And if it were done in a very widespread way, somebody would probably notice and the repo would come under scrutiny. It would probably be very effective as a directed attack against a small number of people, especially if the code you executed was sneaky (i.e., install a rootkit, not `rm -rf /`).

[Bahamut]

All it takes is one dependency getting infected to ruin your day (or more).

[mikeash]

You can at least in theory inspect the library code after cloning it but before compiling it. Insta-owning your machine just because you cloned it is considerably worse. This is especially true if you always run the library in a sandbox of some sort (e.g. you're building an Android app and your code always runs on an Android device or emulator).

[dlubarov]

With Android apps you still build locally, typically with Gradle, allowing arbitrary code execution on the host.

[mikeash]

Oh yes, I suppose a bad build script could undo you. In the land of iOS there are sometimes "libraries" that are just distributed as source files that you add to your own project, so I suppose that at least would qualify.

[mike_hearn]

Additionally, are you willing to bet that there are no buffer overflows in gcc, sed, awk, and whatever other tools you use to build software from git on a regular basis?

Heck, some of the Google security guys have been discovering lately that you can pwn someone just by getting them to run less on a file. How many people start by doing "less README"?

Git should ideally not have this vulnerability, but panicking over this seems overkill. If you want to suck down and work with large amounts of code from a possibly malicious source, you get into virtual machines territory.

[ngoldbaum]

The CVE affects mercurial as well according to the 3.2.3 release notes.

[durin42]

Yes, I asked for a CVE ID for hg but the mitre folks never got back to me.

[indygreg2]

More back story: https://twitter.com/indygreg/status/545701974671233024