Git client vulnerability announced

Post by lucaspiller » Fri, Dec 19, 2014, 12:35 PM UTC

necubi wrote: post #8

Homebrew just updated ( https://github.com/Homebrew/homebrew/pull/35105 ), so Homebrew users should be covered by brew update && brew upgrade git

Post by spdegabrielle » Fri, Dec 19, 2014, 12:58 PM UTC

archagon wrote: post #160

userbinator wrote: post #114

I think here is a good argument for not using case-insensitive filesystems - because every single filename comparison gets affected and it can lead to vulnerabilities like this (I wonder what others are out there...) Case-insensitive initially feels like a good idea to some, but I think it's a good example of "trying to do too much" and often in subtle ways that even the user might not fully understand - the definiti…

The OS should always be in service of the user. And users (in my experience) vastly prefer case insensitivity. Sorry, but there's just no way around it.

Post by spdegabrielle » Fri, Dec 19, 2014, 1:09 PM UTC

hjnilsson wrote: post #141

userbinator wrote: post #114

I think here is a good argument for not using case-insensitive filesystems - because every single filename comparison gets affected and it can lead to vulnerabilities like this (I wonder what others are out there...) Case-insensitive initially feels like a good idea to some, but I think it's a good example of "trying to do too much" and often in subtle ways that even the user might not fully understand - the definiti…

The issue here is not case-insensitive filesystems, they are a huge benefit to novice users. But that the type system does not distinguish between paths and strings. A path is distinctly different from a string, and should never be compared as one. The type system should always enforce this and never allow you to mistakingly do the comparison you propose, for exactly the reasons you state. Modern filesystem libraries…

Post by orbitur » Fri, Dec 19, 2014, 1:33 PM UTC

FiloSottile wrote: post #5

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…

Post by orbitur » Fri, Dec 19, 2014, 1:43 PM UTC

userbinator wrote: post #135

thedufer wrote: post #127

Earlier quoted context omitted.

> Unicode characters that are visually identical This was actually a further bug, reported as part of the same CVE - you could also overwrite .git/config by adding any of a number of zero-width Unicode characters that many filesystems ignore when checking for filename equality (but string comparison doesn't, of course).

http://en.m.wikipedia.org/wiki/Unicode_equivalence http://en.m.wikipedia.org/wiki/IDN_homograph_attack What seems really scary about this is that even Unicode has several different ways of comparing strings, and the correct one depends on the exact situation, so the common response of "just use a library" doesn't work; for example, if a user were searching for a filename it might make sense for full-width characters…