Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git client vulnerability announced

github.com

Post reply on HN
Print view View original

171–180 of 191 posts

Re: Git client vulnerability announced

#171

Post by kdeldycke »

rimantas wrote: post #152
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…

I once tried to install OS X with case sensative filesystem. Turns out Photoshop for OS X does not work in that case. Had to go back to case-insensitive. Not sure how many other apps have the same issue.

Also had issues with steam. The solution ? Install it in a disk image: https://github.com/kdeldycke/dotfiles/commit/05cef3c1de4a208...

Re: Git client vulnerability announced

#172

Post by oneeyedpigeon »

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.

Can you elaborate on that experience? I would have thought users not typing filenames wouldn't care less, and that users who are typing filenames would tend to be developers or 'advanced' users who aren't confused by case-sensitivity, and recognise the advantages.

Re: Git client vulnerability announced

#173

Post by oneeyedpigeon »

orbitur wrote: post #170
userbinator wrote: post #135

Earlier quoted context omitted.

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…

I don't understand. Why can't a library just compare strings at the code-point level, ignoring "canonical equivalence"?

"for example, if a user were searching for a filename"

It's useful when I search for "café", if I also get results for "cafe" - Chrome's search does this. Not to mention searching for "don't" and getting hits including "don’t". But that should definitely be restricted to text data operations, rather than lower-level ones, including filenames.

Re: Git client vulnerability announced

#174

Post by oneeyedpigeon »

yourad_io wrote: post #120
yourad_io wrote: post #113

Earlier quoted context omitted.

Git devs made the incorrect assumption that saving .giT/cONFIg to disk, would actually save .giT/cONFIg to disk. Ridiculously enough, this is not always the case (I weep for us). Should they have known that Windows and MacOS sport case-insensitive filesystems? Definitely. But, how does this have anything to do with bloat or complexity?

And the case-sensitivity stuff is somewhat low-hanging fruit, but... On Windows, certain path components that are different from ".git" are mapped to ".git", e.g. "git~1/config" is treated as if it were ".git/config". HFS+ has a similar issue, where certain unicode codepoints are ignored, e.g. ".g\u200cit/config" is treated as if it were ".git/config" So that's what ridiculous means. Huh.

Oh my lord. That's just Windows being vulnerable, rather than git though, right? No way every piece of Windows software protects adequately against that ... misfeature.

Re: Git client vulnerability announced

#175

Post by userbinator »

oneeyedpigeon wrote: post #172
archagon wrote: post #160

Earlier quoted context omitted.

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.

Can you elaborate on that experience? I would have thought users not typing filenames wouldn't care less, and that users who are typing filenames would tend to be developers or 'advanced' users who aren't confused by case-sensitivity, and recognise the advantages.

That's how I see it too - inexperienced users will only be typing in filenames to name new files and likely use a GUI filechooser for selecting existing ones, while the ones typing in filenames are probably using CLIs.

The common complaint "but it's annoying to have to type in the filenames exactly" can be solved with tab-completion (I'm surprised how many CLI users don't know their shell has this feature), and using sane naming conventions like not GiVinG yOuR fIleS_stUpiD-NaMESLikEth1s.

Re: Git client vulnerability announced

#176

Post by peff »

comex wrote: post #64
peff wrote: post #19

Earlier quoted context omitted.

You were and are vulnerable to malicious projects by running: git clone git://... make or anything similar, since you are running arbitrary code out of the repository. This release fixes the problem of: git clone git://... git show etc. Git cannot fix the "clone and run" problem, which is a social one. But it should be safe to run git commands to inspect the repository contents.

I don't think the GP should be downvoted. What you say is exactly correct - however - I can't even think of a time I've git cloned some piece of code and not proceeded to run some code from it at some point, typically on the same machine. I download code for the purpose of using it, and while I could hypothetically inspect the entire repository for malicious code, I don't think I'm unusual in not doing that on a regu…

I think we are actually agreeing.

I think it is important to have this Git fix, because it lets people be careful if they choose. But in practice most people are _not_ careful, and will happily clone and run code without inspecting it (or pipe curl to bash!). It's almost impossible to do otherwise, as there are only so many hours in the day.

Ultimately I think we are mostly protected by the fact that this kind of attack is simply not all that common. And if it were done in a very widespread way, somebody would probably notice and the repo would come under scrutiny. It would probably be very effective as a directed attack against a small number of people, especially if the code you executed was sneaky (i.e., install a rootkit, not `rm -rf /`).

Re: Git client vulnerability announced

#177

Post by oneeyedpigeon »

im3w1l wrote: post #133
akerl_ wrote: post #74

Earlier quoted context omitted.

I'm not sure how I feel about programs phoning home like that. I tolerate it with apps, but command line tools ought to be doing their stated function when run.

It can be done in a way that preserves privacy: Package manager regularly asks for compromise information. When programs run, they ask package manager if they are compromised.

That still feels like asking too much of each individual program. I'd prefer it if the package manager did the check itself periodically.

Re: Git client vulnerability announced

#178

Post by mikeash »

mike_hearn wrote: post #151
mikeash wrote: post #118

Earlier quoted context omitted.

Oh yes, I suppose a bad build script could undo you. In the land of iOS there are sometimes "libraries" that are just distributed as source files that you add to your own project, so I suppose that at least would qualify.

Additionally, are you willing to bet that there are no buffer overflows in gcc, sed, awk, and whatever other tools you use to build software from git on a regular basis? Heck, some of the Google security guys have been discovering lately that you can pwn someone just by getting them to run less on a file. How many people start by doing "less README"? Git should ideally not have this vulnerability, but panicking over…

I'm sure there are such bugs, but a bug's severity doesn't decrease just because there are other bugs of similar severity elsewhere.

Re: Git client vulnerability announced

#179

Post by userbinator »

oneeyedpigeon wrote: post #173
orbitur wrote: post #170

Earlier quoted context omitted.

I don't understand. Why can't a library just compare strings at the code-point level, ignoring "canonical equivalence"?

"for example, if a user were searching for a filename" It's useful when I search for "café", if I also get results for "cafe" - Chrome's search does this. Not to mention searching for "don't" and getting hits including "don’t". But that should definitely be restricted to text data operations, rather than lower-level ones, including filenames.

But that should definitely be restricted to text data operations, rather than lower-level ones, including filenames.

The issue arises when this "text data" includes filenames. Having café.txt and cafe.txt be equivalent when searching is useful, but the real problem is if a filesystem decides that two "equivalent" filenames are essentially identical - to contrive an example, suppose it thought /étc/passwd was referring to the same file as /etc/passwd . It makes checking for and filtering out "sensitive" filenames far more difficult. For example, just take a look at all the ways Unicode homoglyphs and "special" characters can be used to bypass forum wordfilters, and you'll see how difficult that problem is.

(I know permissions, ACLs, etc. can help here with access control, but the problem of distinguishing between filenames still stands.)

Re: Git client vulnerability announced

#180

Post by ydant »

wereHamster wrote: post #159
rimantas wrote: post #152

Earlier quoted context omitted.

I once tried to install OS X with case sensative filesystem. Turns out Photoshop for OS X does not work in that case. Had to go back to case-insensitive. Not sure how many other apps have the same issue.

World of Warcraft (and any other Blizzard game) won't run off of a case sensitive filesystem.

Steam also requires case-insensitive filesystem on OSX.
Post reply on HN