Short panic summary: your git/hg remotes can get code execution on your machine when you clone/pull if you are on OSX or Windows.
Summary: on case-insensitive/normalizing filesystems (default on OSX and Windows) it's possible for .git/config to be overwritten by the tree, probably due to a case-sensitive sanity check when the actual file is insensitive. .git/config can contain arbitrary commands to be run on certain events/as aliases, so it leads to code execution. This is a risk when you get a tree from a third party, so on pull/fetch+checkout/clone...
There's an analogous vulnerability in Mercurial.
Update, then run git --version and make sure it's one of v1.8.5.6, v1.9.5, v2.0.5, v2.1.4, or v2.2.1. And be careful when pulling/cloning from third-parties.
EDIT: right, no "or", what are you doing reading this instead of updating?
Yes, the actual vulnerability is that you can commit .Git/config or .gIt/config etc., and on case insensitive filesystem, checking that out will overwrite .git/config.
My quick an dirty (pun intended) experiment concluded that ntfs, while mounted on linux, is case-sensitive. Windows will happily list all files from fs in explorer, whatever case they are, but treat them as one. And this is deep in win32: http://i.imgur.com/sWnCMdq.png (that's cygwin, while on linux, I've put a `small` file in the `test` dir).
You can mount NTFS case sensitive, but you probably don't want case sensitivity if you interop with Windows and, if you don't, why on earth would you use NTFS?
NTFS is case sensitive. The Win32 layer presents NTFS as case preserving, but the NT POSIX layer (since renamed to SFU), as well as Cygwin, use NTFS's case sensitivity.
More to the point, the NTFS API can be both. And you can access that from Win32 code as well. There's also a registry flag to make NTFS case-sensitive by default.
I just quickly tested this on Windows 7. It showed both a directory for both spelling, but both of them contained the same content corresponding to one of the two directories.
Probably a fairly common case: I use git on a Linux VM running in a Mac OS X host machine, using an NFS synced folder to share files between the host and guest. It appears that in this case the guest machine uses the case insensitivity of the host file system, making git vulnerable even though it's running on Linux.
So, I guess people are going through old web server vulnerabilities such as trying to masquerade ".git/config" as ".git/../.git/config" or using different encodings for the same file to see which ones git falls for?
Also, can git run with .git/config being read only? That could be a useful second line of defense.
Why SourceForge? Since they changed investors a few years ago, I thought SourceForge now added spameare to installers, such as the Ask toolbar for example?
Summary: on case-insensitive/normalizing filesystems (default on OSX and Windows) it's possible for .git/config to be overwritten by the tree, probably due to a case-sensitive sanity check when the actual file is insensitive. .git/config can contain arbitrary commands to be run on certain events/as aliases, so it leads to code execution. This is a risk when you get a tree from a third party, so on pull/fetch+checkout/clone...
There's an analogous vulnerability in Mercurial.
Update, then run git --version and make sure it's one of v1.8.5.6, v1.9.5, v2.0.5, v2.1.4, or v2.2.1. And be careful when pulling/cloning from third-parties.
EDIT: right, no "or", what are you doing reading this instead of updating?