Git client vulnerability announced • Hacker News Board

Re: Git client vulnerability announced

#101

Post by dlubarov » Fri, Dec 19, 2014, 12:40 AM UTC

mikeash wrote: post #46

califield wrote: post #14

Earlier quoted context omitted.

Yeah, but typically you have a certain level of trust in your project dependencies. Adding a library to your project often means granting access to your system anyway (if the dependency contains executable code).

You can at least in theory inspect the library code after cloning it but before compiling it. Insta-owning your machine just because you cloned it is considerably worse. This is especially true if you always run the library in a sandbox of some sort (e.g. you're building an Android app and your code always runs on an Android device or emulator).

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

Re: Git client vulnerability announced

#102

Post by mbrubeck » Fri, Dec 19, 2014, 12:40 AM UTC

dshankar wrote: post #54

mbrubeck wrote: post #44

Earlier quoted context omitted.

It also includes a link to msysgit for Windows. If you need some type of binary not listed, it would help if you mention what type of binaries you need.

Fair point. I was looking for Mac binaries. Homebrew ending up being the quickest way to upgrade git, as much as I dislike using Homebrew :)

Ah, got it. I hadn't noticed the lack of a Mac binary link in the post.

Re: Git client vulnerability announced

#103

Post by mholt » Fri, Dec 19, 2014, 12:45 AM UTC

> 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.

What about case-sensitive Mac file systems, like mine? I would imagine they are not vulnerable and that the author just overlooked this possibility in the article...

Re: Git client vulnerability announced

#104

Post by the_af » Fri, Dec 19, 2014, 12:55 AM UTC

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…

I agree Git can be complex, but... CVS? Really? I do not miss non-atomic commits at all.

Re: Git client vulnerability announced

#105

Post by akerl_ » Fri, Dec 19, 2014, 12:58 AM UTC

semi-extrinsic wrote: post #83

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.

There was a discussion of this a few weeks ago on the mailinglist of a scientific software project I use. The people were very clearly divided into the "Flash does it, so it's ok" and "omg no, think of the user privacy" camps, it was quite interesting.

I think I'm much more ok with background things upgrading in the background. For instance: I never open a new browser tab and think "hmmm, lets launch a Flash process", it's just there, ready to respond when needed. So it isn't shocking to find that it polls for updates and applies them.

By contrast, git is a tool that I manually invoke on the command line, and when the process terminates it's done. Having that phone home at runtime feels more invasive.

Re: Git client vulnerability announced

#106

Post by gklitt » Fri, Dec 19, 2014, 12:59 AM UTC

cbd1984 wrote: post #87

fizzbatter wrote: post #59

Earlier quoted context omitted.

Well, to be clear, this only affects Mac and Windows, correct? (Technically any case changing os) So, update no matter what, unless you're not on an affected system? (this is a question, not a statement)

OK, just so everyone is up to speed: Under what circumstances could a Linux filesystem be case-insensitive? I know of three: FAT (specifically vfat, these days), JFS with Option -O, and CIOPFS (Case Insensitive On Purpose Filesystem): http://superuser.com/questions/290480/case-insensitive-parti... http://linux.die.net/man/8/mkfs.jfs http://manpages.ubuntu.com/manpages/hardy/man8/jfs_mkfs.8.ht... http://www.brain-dump…

Probably a fairly common case: I use git on a Linux VM running in a Mac OS X host machine, using an NFS synced folder to share files between the host and guest. It appears that in this case the guest machine uses the case insensitivity of the host file system, making git vulnerable even though it's running on Linux.

Re: Git client vulnerability announced

#107

Post by icebraining » Fri, Dec 19, 2014, 1:00 AM UTC

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…

CVS has had multiple arbitrary code execution vulnerabilities, though.

Re: Git client vulnerability announced

#108

Post by mathrawka » Fri, Dec 19, 2014, 1:02 AM UTC

the_af wrote: post #104

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…

I agree Git can be complex, but... CVS? Really? I do not miss non-atomic commits at all .

The point is that for OpenBSD that security trumps anything else, including usability of developer tools.

Re: Git client vulnerability announced

#109

Post by SSLy » Fri, Dec 19, 2014, 1:11 AM UTC

ethomson wrote: post #96

cbd1984 wrote: post #87

Earlier quoted context omitted.

OK, just so everyone is up to speed: Under what circumstances could a Linux filesystem be case-insensitive? I know of three: FAT (specifically vfat, these days), JFS with Option -O, and CIOPFS (Case Insensitive On Purpose Filesystem): http://superuser.com/questions/290480/case-insensitive-parti... http://linux.die.net/man/8/mkfs.jfs http://manpages.ubuntu.com/manpages/hardy/man8/jfs_mkfs.8.ht... http://www.brain-dump…

As for common filesystems (for some reasonable value of "common"): NTFS, HFS+ and SMB will probably be case insensitive. ZFS may be case insensitive. There are others that would be exotic these days, like AFP. And with FUSE, could be anything.

My quick an dirty (pun intended) experiment concluded that ntfs, while mounted on linux, is case-sensitive. Windows will happily list all files from fs in explorer, whatever case they are, but treat them as one. And this is deep in win32: http://i.imgur.com/sWnCMdq.png (that's cygwin, while on linux, I've put a `small` file in the `test` dir).

Re: Git client vulnerability announced

#110

Post by gbog » Fri, Dec 19, 2014, 1:16 AM UTC

icebraining wrote: post #107

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…

CVS has had multiple arbitrary code execution vulnerabilities, though.

Yes, but the point is that vulnerabilities in cvs are likely very few as of today, because the code is old and simple, and have been used a lot.