Slashdot Mirror
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."
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.
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?
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.
How can I believe you when you tell me what I don't want to hear?
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...
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.
Irony: Agile development has too much intertia to be abandoned now.
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.
There's no place I could be, since I've found Serenity...
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)."
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.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
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.
Irony: Agile development has too much intertia to be abandoned now.
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.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?