Critical Git Security Vulnerability Announced

An anonymous reader writes Github has announced a security vulnerability and has encouraged users to update their Git clients as soon as possible. The blog post reads in part: "A critical Git security vulnerability has been announced today, affecting all versions of the official Git client and all related software that interacts with Git repositories, including GitHub for Windows and GitHub for Mac. Because this is a client-side only vulnerability, github.com and GitHub Enterprise are not directly affected. The vulnerability concerns Git and Git-compatible clients that access Git repositories in a case-insensitive or case-normalizing filesystem. An attacker can craft a malicious Git tree that will cause Git to overwrite its own .git/config file when cloning or checking out a repository, leading to arbitrary command execution in the client machine. Git clients running on OS X (HFS+) or any version of Microsoft Windows (NTFS, FAT) are exploitable through this vulnerability. Linux clients are not affected if they run in a case-sensitive filesystem....Updated versions of GitHub for Windows and GitHub for Mac are available for immediate download, and both contain the security fix on the Desktop application itself and on the bundled version of the Git command-line client."

Comments

Only bad for pulling untrusted content.

[Anonymous Coward]

This is only an issue if you pull untrusted content, and are on a case insensitive file system. This is not typical git usage, but its a good thing to know about.

If you do thing like pull from a repo, and run the build scrips without reading them first, you already had worse security problems, and there is nothing worse about this. It seems like the main fear would be (case insensitive) servers doing automated pulls and such getting compromised by hostile repo.

Servers that pull from lots of git repos could spread such attacks virus style, but I really don't think many such networks of auto git pulling servers exist. More likely is a specific targeted attack against some servers, but I expect most run on case sensitive file systems.

Unrelated to Github

[Anonymous Coward]

I'm puzzled that Github is stated as the main actor here. They are just
broadcasting the official announcement from the git mailing list. They are not
involved in the initial discovery, subsequent investigations or fixes. How come
this post end up giving them most of the credit? Have people already
forgot that Git and Github are different entities?

Re:Unrelated to Github

[Anonymous Coward]

The headline is wrong too. This isn't a Git vulnerability. This is a flaw in Windows and Mac OS X where they fail to differentiate between two similar but different file names. That Git has a workaround for their broken behavior is good in the short run, but the correct solution would be to fix Windows and Mac OS X so that they can tell the difference between upper and lowercase letters.

Re: Unrelated to Github

[forand]

You can run OS X on an encrypted case-sensitive file system without any issue. This is nota bug of windows and Mac but a bug of git allowing its own files to be overwriten because it thinks it knows better than the file system what a file is named.

Re:Unrelated to Github

[KingMotley]

WTF is Git? Is that a new fork of git? Cause I can't tell what you are talking about because you put the wrong case.

Re:Unrelated to Github

[fph il quozientatore]

Please, that's GNU/git.

Re:Unrelated to Github

[Kjella]

Tag: NOTABUG and WONTFIX. Case aware filesystems so you can have normal names and not like AUTOEXEC.BAT and CONFIG.SYS from the DOS days is great, case sensitive file systems are a really bad idea. Is there any kind of sane situation where you'd like to have two files "Config" and "config" actually coexist that isn't just begging to be confused/abused/exploited? For a marginal performance optimization all POSIX systems have shitty usability. Why am I not surprised? I guess for a server it just doesn't matter, but for the desktop you should file this as a bug against Linux, not Windows and OS X.

Re:Unrelated to Github

[jeremyp]

No it isn't.

Both NTFS and HFS+ are file systems that are case insensitive and case preserving (by default). They work as designed. They have always worked that way as the people who ported git to those platforms should have known.

Just because you don't like the way NTFSD and HFS+ work and it makes the programmer's job a little harder doesn't mean there is a bug.

Re:I blame Microsoft

[pushing-robot]

Yeah, what's next? Case-insensitive email addresses and domain names?

Remember, the whole reason files have names and not sequences of random hex is for human legibility. For most applications, case sensitivity does not increase legibility.

Mac OS X does support case-sensitive filesystems

[mean pun]

Keep in mind that Mac OS X supports case-sensitive HFS+ filesystems, and has done so from Mac OS X 10.3 on (2003). All you have to do is create a partition with that particular flavour of HFS+.

However, Adobe refuses to support case-sensitive filesystems. The Photoshop installer refuses to install on a case-sensitive filesystem, and Lightroom geolocation support is broken on case-sensitive filesystems, and always has been. Of course this limitation is not documented in their sales documentation, and the official fix is to reformat the partition...

Re:I blame Microsoft

[Dutch Gun]

Karma be damned...

One could alternately argue: do you feel it's a good thing for something.dat and Something.dat to reference two different files? Because that would never confuse users, right? Shall we next talk about forward slash versus backslash in path separators, and how one is obviously much more logical and intuitive than the other? Or maybe we should get into line endings, or perhaps how there really shouldn't be any distinction between text and binary files? UTF-8 vs UTF-16?

Newsflash: different operating systems have different conventions and different quirks. I'm going to take a wild-ass guess and predict that you believe the choices of your preferred OS are obviously the correct choices.

Re:I blame Microsoft

[cbhacking]

Actually, Microsoft themselves has an API for accessing NTFS drives in a case-sensitive manner, and I'm not talking about the native NT API or even the FILE_FLAG_POSIX_SEMANTICS Win32 file API flag. All versions of NT from 3.1 (the first) to 6.2 (Win8; it was removed from 8.1) have support for a POSIX operating environment - basically a full Unix-like OS running atop the NT kernel - and for proper Unix-like-ness it is case sensitive.

Mind you, Win32 programs do tend to get confused by it all. For example, CMD's "dir" command will list both "test.txt" and "TEST.TXT" in the same directory, and even correctly note if they have different sizes or datestamps. However, the "type" command (print file contents) on *either* name (or some other-cased version of the name) will instead print the contents of one of the files - doesn't matter what you type, the OS will pick - and it will print it twice (once for each copy of the file with that name).

I've been using the Interix (name of the Unix-like operating environment that runs in the NT POSIX subsystem, as reported by the uname command) build of git for years now. I should probably stop - the repo my package manager used has died, and I haven't bothered to set up a different package manager yet so my packages are outdated - but I am, humorously enough, not vulnerable to this particular attack even with that outdated version.

polish != Polish

[Anonymous Coward]

Yeah, what's next? Case-insensitive email addresses and domain names?

Remember, the whole reason files have names and not sequences of random hex is for human legibility. For most applications, case sensitivity does not increase legibility.

You are conflating two things that are (or should be) separate: the file system and the UI.

The file system (paths and names) should be case sensitive. If I give the VFS a string of bits that represents a file's name (regardless of ASCII, Unicode, or EBCDIC) it should take those bits and store them as-is and give them back as-is with interpreting them.

The UI (whether the GUI or maybe the CLI shell) could then make things easier for humans by treating "p" like "P", but the file system should treat them differently.

There is a difference after all between "Polish metal" (geographic connotations) and "polish metal" (to make shiny). Or, as another example, the sentences "I helped my Uncle Jack off a horse" and "I helped my uncle jack off a horse". If you want to have your GUI/CLI treat them the same, go ahead (just set your $LC_COLLATE appropriately), but don't bake that shit into the VFS or FS.

HFS+ switched from Unicode 2.1 to 3.2 decomposition/normalization a few years back which caused issues for git:

http://marc.info/?l=git&m=120104708602274&w=3

Really: a file system should give back exactly what was put into it (both in terms of files and data).

Re:polish != Polish

[Dutch Gun]

You know, one could argue that case sensitivity in file systems actually demonstrates the difference between the *nix vs. Windows philosophies pretty well. Disclaimer: I'm a Windows guy, so let me know if I'm making unfair characterizations.

*nix

*nix is about power, flexibility, and user control. It favors command-line interaction through discrete commands, applications, and scripts. This makes it extremely suitable for power-users and administrators who are willing to invest the time to become proficient in using these tools. Visual interfaces are often built on top of these command-line actions, which can create a slightly disjointed experience for more casual users who don't understand what's happening under the hood or can't easily fall back to command-line use when needed.

File system design: A file system should give back exactly what was put into. We should provide maximum flexibility and utility, even if it comes at the expensive of user-friendliness. The entire system should not be dumbed down to protect users who can't even figure out how to properly name their files, because there may be legitimate use cases for case sensitivity in file naming.

Windows

Windows is about user-friendliness. Visual tasks and interactions are emphasized over command-line actions. Applications are often extended through proprietary extensions or internal scripting rather than through command-line input and output. Because the system is build with visual interaction in mind first and foremost, users never have to interact with a command-line. This makes it easier for casual users to achieve faster results with less training, but can come at the cost of a more shallow understanding of their computers (e.g. if the visuals change significantly, users may become confused).

Filesystem design: We can't really think of a reasonable use case in which a user would actually want to create two different files in the same directory that only differ by case. In reality, it would probably be the result of an mistake, and this may cause confusion for users. Therefore, we'll just restrict the functionality to eliminate that potential error. We're willing to write a bit of extra code to preserve case but to discard it when disambiguating files.

Re:I blame Microsoft

[by (1706743)]

I think there is a bit of a difference, though -- email addresses and domain names are typed by hand by the "average" (read: GUI-only) user on a day-to-day basis. That filenames were case-insensitive probably made a lot more sense back when the average user had to type at a command line -- in which case yeah, it probably was a better UX to have case-insensitivity (at least, from a casual user's perspective). In today's world of GUIs, case sensitivity might not increase legibility -- but it doesn't decrease legibility either, and is (I think?) a POSIX violation.

Despite the fact that I think case-sensitivity is a Good Idea, I really like zsh's ability to tab-complete in a case-insensitive fashion :)

Re:I blame Microsoft

[by (1706743)]

An AC above somewhere (comment: "polish != Polish") had a great comment: there's a difference between the filesystem and the UI. If a UI (file manager, shell, etc.) wants to reference two different files in a different fashion, fine. But the filesystem "should give back exactly what was put into it (both in terms of files and data)."

Re:Case insensitive file systems were a bug

[Anonymous Coward]

It's another bit of pandering to the stupid. Rather than encourage people to go into the direction of sanity, the path of least resistance is to turn the bug into a feature. Microsoft and Apple are both guilty of that. Encouraging whitespace in file names is another indicator of this.

I don't let Unix and descendants get off so lightly, either. While they have sanity w/r/t filename case and the use of slash as a path-element-separator character, they do allow allow not just blanks but also control characters as well as spaces in file names. While it is possible to make a case for such characters in names, I think possibilities for error and misuse far outweigh the advantages.

Re:Case insensitive file systems were a bug

[aardvarkjoe]

Obviously every character except for the path separator and the string terminator should be valid. Why should the file system restrict what character encoding I want to use for my names other than restrictions that simply make implementation easier.

This article makes a pretty convincing case that we'd be better off with some restrictions on filenames. It's hard to argue the point that allowing certain characters in filenames causes more problems than it solves.

Re:Mac OS X does support case-sensitive filesystem

[kthreadd]

Keep in mind that Mac OS X supports case-sensitive HFS+ filesystems, and has done so from Mac OS X 10.3 on (2003). All you have to do is create a partition with that particular flavour of HFS+.

Stepping back from HFS+ they've even supported case-sensitive file systems long before that since you could use UFS on OS X. Even OS 9 supported it but I don't remember if you could boot that from it.

However, Adobe refuses to support case-sensitive filesystems. The Photoshop installer refuses to install on a case-sensitive filesystem, and Lightroom geolocation support is broken on case-sensitive filesystems, and always has been. Of course this limitation is not documented in their sales documentation, and the official fix is to reformat the partition...

Yep. The Adobe suite won't even open files over NFS.

Re:SVN?

[jez9999]

I have source trees that I can't check out of an SVN server on windows because either the files get overwritten by different case filenames being aliased onto the same file

Windows' behaviour makes sense. What doesn't make sense is having Readme and readme in the same directory. What possible reason could one have for differentiating 2 files on nothing but case?

Re:Case insensitive file systems were a bug

[aardvarkjoe]

A quick glance at that article seems more like a compelling case for teaching people how to write shell scripts properly.

If you read the article, you'll find that writing shell scripts to handle filenames containing every possible character "properly" is so difficult that virtually everyone gets it wrong. When something's been around for close to 40 years and still nobody can get it right, maybe it's time to admit that it's the tool that's broken.