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."
For creating case-insensitive file systems.
What.
The.
Fuck.
Case insensitive file systems were always a bug. They started back when DOS used a file system that used an encoding that simply didn't have lowercase letters. That they persisted into Windows was a bug that Microsoft never fixed.
...are the dumbest thing ever.
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?
This article would make for a great drinking game - take a drink every time 'git' is mentioned.
This isn't a specific git problem. It's a windows problem.
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 or the file tree being to deep for windows.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
No developer worth mentioning runs OS X with a case insensitive file system, and there are only 2 sets of Applications that don't work on case sensitive file systems on OS X: ... well I have no fucking idea why steam doesn't support case sensitive volumes on OS X when it does so on Linux ... regardless of the fact that everyone else for OS X except Adobe and Valve are capable of doing so OUT OF THE BOX WITH NO MODIFICATIONS TO THEIR SOFTWARE ... oh and Adobe has never presented an example of how the tools are broken illustrating their problem, they just keep saying 'broken tools! broken tools!'
Steam - because
Adobe * - Because according to Adobe the Apple development toolchain doesn't work right and so they can't support case sensitivity
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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...
Adobe may be referring to a lack of a conversion tool to do the work for them. Seriously, do want Adobe's coders to be in charge of a task like that? 50 OS-crashing betas before they release a working version 5 years later.
So does Windows, though you may confuse the Win32 API if you use it. NTFS is case-preserving and the native APIs are case-sensitive. Win32 functions can use FILE_FLAG_POSIX_SEMANTICS to require case-sensitivity, and Interix (Microsoft's POSIX-on-NT environment that runs in the Subsystem for Unix Applications or SUA) does so by default. I don't know of any way to make Win32 case-sensitive by default without doing some kind of crazy hooking of the relevant APIs or installing a filter driver to enforce it.
There's no place I could be, since I've found Serenity...
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).
I guess that makes you special?
Except this can install hooks, and thus automated executable you will then run. You might not realize that pulling from a git repository could run arbitrary code.
There is a difference after all between "Polish metal" (geographic connotations) and "polish metal" (to make shiny).
Not at the beginning of a sentence.
Or, as another example, the sentences "I helped my Uncle Jack off a horse" and "I helped my uncle jack off a horse".
Or better yet, "I went to my Uncle Jack's stud farm and helped him jack off a horse". Not that there's anything wrong with that.
I told you so.
But whoever uses Windows or OSX deserves all the pain (s)he gets.
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.
I fail to see how a more feature-rich file system interferes with software installation, unless they depend on a bug, which then should probably be filed and fixed.
However additionally I would add: *nix is also about Pedantic-ness. It ensures filenames you write/access on *nix will work the same on all filesystems, or will error the same on all filesystems. The big example of this is *nix developed programs vs Windows developed ones. The *nix build system/includes will all have the proper case/name of files included and referenced in the EXACT SAME MANNER, whereas an application developed on Windows that is now being tested on *nix will oftentimes fail due to developer shortcomings (either a lazy inconsistent programmer, or a few dozen different developers for the same project) who have strewn the code with mismatched case #includes (IE HashFileSystem.h vs hashfilesystem.h vs hashFilesystem.H, with the actual file name being HASHFILESYSTEM.H) which the 'porting' developer will now have to go through and fix every referemce to, as well as potentially dozens to thousands of filenames (Not a big deal if you just need to lowercase all of them, and then lowercase all the include names, but potentially a HUGE deal if all the filenames use capitalized words/classes/source files, java-style.)
This has been one of the biggest messes I've run into in regards to 'exclusive' windows developers, and even on open source projects, many of them are 'elitist' enough to consistent break cross platform compatibility through sloppy use of filenames, or trying to use a 'leet function call' that isn't actually cross platform compatible.
So the Flash installer on Windows is not the only badly implemented installer from Adobe? On Windows, the first thing it does is to delete the installer executable itself. And then it usually does a minute of installation, which fails with "something happened, please try again" -dialog. Of course, the retry starts with re-download, and perhaps on third attempt, one learns to make a copy of the installer before running it :-)
I've never been able to make much sense of Adobe's stance in this, but as far as I can tell Adobe thinks that case-sensitive file systems are useless and if they wait long enough they will go away.
I vaguely remember that one version of Photoshop failed on case-sensitive volumes, and there was a patch circulating that fixed about 9 filenames scattered throughout the code, and solved the problem. Rather than applying this patch, Adobe chose to block installation on case-sensitive volumes in modern versions.
It doesn't exist in ANYTHING other than GitHub's Windows and OSX clients that do provably **WRONG** things. It doesn't exist in other Git clients.
Guys... /.'s editorial content has *REALLY* slid over time- this is just simply bad journalism, etc.
Enjoyed skimming through it, especially the point about character encoding and the value of utf-8. Many arguments for name restrictions are because it would make shell commands and scripts easier to write correctly. That suggests to me the bigger issue is the shell.
As the computer language Forth shows, there does not have to be an obvious line between a programming language and a command line. It's unfortunate our systems generally have multiple languages with different conventions. What might be better is a good language with levels of parsing, sort of like the difference between JSON and JavaScript, or HTML/CSS and JavaScript, where some levels are not intended to have executable code and the system knows that. Anyway, just a seed of an idea.
Just to try to grow it a bit, imagine if (shudder, as I prefer Smalltalk syntax) we used JavaScript as a "shell" syntax. When you wanted to delete a file, you might enter:
$ File.remove(["force"], "file name with spaces or not");
instead of:
$ rm -f file\ name\ with\ spaces\ or\ not
Actually, I prefer the JavaScript version. :-)
Because JavaScript is so flexible, you could do in some JavaScript shell profile:
var rm = File.remove;
var rmf = rm.bind(["force"]);
Then, with assumed semicolons you could write:
$ rmf("file name with spaces or not")
That seems much clearer to me than the conventional shell script notation.
Commands could return JavaScript objects for results, displayed as JSON. So:
$ File.list()
{"test1.js", "test2.js"}
$ File.list(["long"])
{".": ["drwxr-xr-x+", "pdfernhout", "staff ", 2822, "2014-12-03Z08:14"], /*", ["drwxr-xr-x+", "pdfernhout", "staff ", "1234", "2014-12-03Z08:14"]}
"..": ["drwxr-xr-x+", "pdfernhout", "staff ", 2822, "2014-12-03Z08:14"],
"test1.js", ["drwxr-xr-x+", "pdfernhout", "staff ", "1234", "2014-12-03Z08:14"],
"test2.js", ["drwxr-xr-x+", "pdfernhout", "staff ", "1234", "2014-12-03Z08:14"],
"-rf", ["drwxr-xr-x+", "pdfernhout", "staff ", "1234", "2014-12-03Z08:14"],
"metacharacter & ||||| weirdness!!!! | rm -rf
$ rm("metacharacter & ||||| weirdness!!!! | rm -rf /*")
$ rm("-rf")
I'm not sure if there would be other stiff like pipes that might trip you up, especially with JavaScript's syntax and single-tasking assumptions. Probably the results of these functions might have to be some form of Deferreds or something like that?
As a first cut at pipes, assuming the result of a previous operation as a JavaScript object is passed as a final argument to the next operation:
$ File.list().then(File.grep.bind("test*")).then(File.write.bind("out.txt"))
Or with appropriate aliases via var and an assumption that "then" does a bind for arguments:
$ ls().then(grep, "test*").then(write, "out.txt")
Seems much easier to me to really understand this. It's a tradeoff of course. You might be typing a few more characters sometimes than for something like Bash, but whenever you tried to do something complex, it might be more understandable than a mess of metacharacters. And then file names (in ut8) without restrictions on metacharacters would not be such a big issue. These functions could even have a case-insensitive option.
with a IMHO human-friendly syntax like one derived from Smalltalk, where you used spaces to separate messages instead of a dot ("."), you would have:
$ (File ls) then: [File grep: "test*"] then:
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
It seems like a no-brainier. If your business decided to use a cloud service for source control - you have no right to your source code and it is a major security hole
Why not host source control in-house? It is plain stupid to assume that code is secure mid transmission with SSH encryption. Cell phones and emails are not secure with stronger security and they do not even have capability to modify code that will be executed.
Github is the next Code Spaces
That's no way to talk about Linus, even if he did leave his door unlocked!
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
tl;dr
Case sensitivity is a good idea. The problem is that trying to do "case insensitive" matching depends on the locale. If you send your files to someone else, whether or not they are the "same" depends on your locale if you're serious. For Turkish users, 'i' and dotted 'I' are the same if you're considering them as case-sensitive; for many other languages and users, the dots create DIFFERENT characters. And if you're trying to make this "easy" it doesn't go far enough; Latin "a" usually looks the same as Cyrillic "". So please don't say "users can't tell the difference" - they ALREADY can't tell the difference visually, and naive solutions do not begin to address it. At least you can visually see the difference betweeen "Picture" and "picture", and in any case, users typically just click on the item and move on.
I think it would be a GOOD idea to require that Unix-like filenames be legal UTF-8 sequences (since you then know how to display them), and then reject filenames that are not UTF-8. But that's much less intrusive than filename mangling.
That said, it's too late to fix Windows, so if you're going to run on Windows you have to deal with the problem as it is.
- David A. Wheeler (see my Secure Programming HOWTO)