Hacker News Reader

Comment by FiloSottile | Hacker News Reader

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?

View on HN

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.

For those wondering about the analogous vulnerability in Mercurial, the patch notes are out for a fix:

http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_3.2.3_....

You'll need 3.2.3 to be secure.

Lose the /or. Update no matter what.

Well, to be clear, this only affects Mac and Windows, correct? (Technically any case changing os)

So, update no matter what, unless you're not on an affected system?

(this is a question, not a statement)

As mentioned in the mailing list announcement (http://article.gmane.org/gmane.linux.kernel/1853266), if you run a git host on linux, you can still spread the dangerous commit.

OK, just so everyone is up to speed: Under what circumstances could a Linux filesystem be case-insensitive?

I know of three: FAT (specifically vfat, these days), JFS with Option -O, and CIOPFS (Case Insensitive On Purpose Filesystem):

http://superuser.com/questions/290480/case-insensitive-parti...

http://linux.die.net/man/8/mkfs.jfs

http://manpages.ubuntu.com/manpages/hardy/man8/jfs_mkfs.8.ht...

http://www.brain-dump.org/projects/ciopfs/

Are there any more?

As for common filesystems (for some reasonable value of "common"): NTFS, HFS+ and SMB will probably be case insensitive. ZFS may be case insensitive.

There are others that would be exotic these days, like AFP. And with FUSE, could be anything.

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?

Yeah. NTFS is case preserving, not case sensitive.

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.

Anyone knows what happens if an NTFS partition has both fiLe and file, when used in windows?

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.

Re zfs, you have to turn case insensitivity off if you want it. The default is case sensitive.

That is: $ zfs get casesensitivity zroot NAME PROPERTY VALUE SOURCE zroot casesensitivity sensitive -

Is what you want in general. Unless you have some reason not to be, in which case you have to worry about the bug.

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.

Or Linux mounting a case-insensitive share, e.g. CIFS.

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.

I just downloaded git from git-scm.org and I only got 2.0.1. :/

It's now available at http://sourceforge.net/projects/git-osx-installer/files/late...

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?

It's opt-in. The spamware doesn't get added automatically, you as a project admin need to enable this.

Hmm. I have git 2.2.0 installed through Homebrew, but the Homebrew repo seems broken at the moment?

edit: Nevermind, short-lived issue. Just upgraded to 2.2.1.

For anyone looking to update via Homebrew, make sure it has the latest formulae:

  brew update
  brew upgrade git

Cygwin and Macports both have versions which are vulnerable.

EDIT: Macports just updated. I did it with

# port selfupdate # port upgrade outdated

and 2.2.1 came down.

If you have the Apple git, then you should

# port install git

Reply on news.ycombinator.com