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

Git: Malicious repositories can execute remote code while cloning

openwall.com

Post reply on HN
Print view View original

101–110 of 228 posts

Re: Git: Malicious repositories can execute remote code while cloning

#101

Post by dragonwriter »

matheust wrote: post #99
floatingatoll wrote: post #6

> if Git is configured globally to apply delay-capable clean/smudge filters (such as Git LFS) What is the simple test for whether this is the case or not? Is this a default-on scenario?

> What is the simple test for whether this is the case or not? As suggested in GitHub's announcement post[1], you can test this with the following: `git config --show-scope --get-regexp 'filter\..*\.process'` (replace the single quotes by double quotes on Windows Command Prompt) > Is this a default-on scenario? On Windows yes, because Git-for-Windows configures Git LFS by default. [1]: https://github.blog/2021-03-09-…

Doesn't Git-for-Windows default configure symbolic link support off, though? Or does this exploit work even in that case as long as the underlying file system supports symlinks?

Re: Git: Malicious repositories can execute remote code while cloning

#102

Post by geofft »

Ancapistani wrote: post #88
caymanjim wrote: post #12

Earlier quoted context omitted.

MacOS by default uses a "case-preserving case-insensitive" filesystem, so you can create files with mixed case, but you can't create two files with the same name and different case. It's one of MacOS's more-egregious crimes against Unix. Fortunately it doesn't manifest that often, but it rears its head often enough to be a problem.

> Fortunately it doesn't manifest that often, but it rears its head often enough to be a problem. IIRC, one place where it does rear its head in when a file is renamed in a git commit to a value that downcases to the same value as the prior name. For example `Foo.txt`->`foo.txt`. I have `core.ignorecase = true` in my `.gitconfig` for this very reason.

The extraordinarily frustrating case is where you're working on a repository that has multiple files that differ only by case. Git will check out one of them, then overwrite it with the other.

The Linux kernel is one of them: several of the headers that get installed to /usr/include/linux/netfilter have conflicts on a case-insensitive filesystem. https://github.com/torvalds/linux/tree/master/include/uapi/l...

Debhelper used to be one of those until I convinced them to change it: they had a Debian/ directory for the Perl module Debian::Debhelper as well as a debian/ directory for the packaging metadata. https://bugs.debian.org/873043

(I suspect I'm a little unusual in wanting to have checkouts of Linux and Debhelper on my Mac homedir.)

Re: Git: Malicious repositories can execute remote code while cloning

#103

Post by bin_bash »

anyfoo wrote: post #93
sethammons wrote: post #65

Earlier quoted context omitted.

well played. I think that just got added to my standard vocabulary. Caching has caused more errors and bugs that I've had to deal with than I can recall. My favorite was an off by one error where we returned nicely cached info -- just for the previous user who came through our system! :facepalm: That was a bad one.

That's because essentially, "state" and "caching" are the same thing on some level. And the problem with state is that you have to make sure all your state transitions don't cause bugs. What we know as a "cache" is essentially creating new state representing existing state, with all new transitions...

Cache is a type of state but not necessarily the other way around

Re: Git: Malicious repositories can execute remote code while cloning

#104

Post by EamonnMR »

leephillips wrote: post #19
caymanjim wrote: post #12

Earlier quoted context omitted.

MacOS by default uses a "case-preserving case-insensitive" filesystem, so you can create files with mixed case, but you can't create two files with the same name and different case. It's one of MacOS's more-egregious crimes against Unix. Fortunately it doesn't manifest that often, but it rears its head often enough to be a problem.

It may be a crime, but is the result of a set of compromises in the design of the OSX filesystem, which had to work with a BSD variant while also being compatible with pre-OSX days. I think it’s one thing they actually did an elegant job with. EDIT: This document describes some of the challenges: https://www.usenix.org/legacy/publications/library/proceedin...

This is the first article I've found that does a decent job of explaining what a resource fork really is.

Re: Git: Malicious repositories can execute remote code while cloning

#105

Post by aiisjustanif »

SilverRed wrote: post #94
jonas21 wrote: post #52

Earlier quoted context omitted.

Isn't the whole point of announcing security patches so that people can update before they're exploited?

Sure, I'm just saying this isn't a big deal and its likely no one was hit.

Just because there is not an active threat doesn’t make it any less of a vulnerability to be exploited.

Re: Git: Malicious repositories can execute remote code while cloning

#106

Post by anyfoo »

bin_bash wrote: post #103
anyfoo wrote: post #93

Earlier quoted context omitted.

That's because essentially, "state" and "caching" are the same thing on some level. And the problem with state is that you have to make sure all your state transitions don't cause bugs. What we know as a "cache" is essentially creating new state representing existing state, with all new transitions...

Cache is a type of state but not necessarily the other way around

In the efficient implementation of a pure functional language (say Haskell without MVars), what really is the difference between state and cache?

I know this is overly philosophical, and in practical scenarios we readily (although not always unambiguously) differentiate between "cache" and "state", but the point about transitions and that being a major source of bugs still stands.

Re: Git: Malicious repositories can execute remote code while cloning

#107

Post by pablius »

imoverclocked wrote: post #53
Twisol wrote: post #43

Earlier quoted context omitted.

It's barely even a joke to me anymore -- it's just too real for me to laugh. (Cache invalidation is essentially the same problem as managing mutable state -- "Out of the Tar Pit" frames mutable state as either essential or incidental, the latter being rederivable in principle from essential state. Incidental mutable state is no more and no less than a cache, and usually one with an informal and undocumented invalidat…

Humor is often the most efficient way to communicate/accept the truth.

To make the truth seem like an acceptable parallel universe, and then join it.

Re: Git: Malicious repositories can execute remote code while cloning

#108

Post by ampdepolymerase »

joubert wrote: post #83
jholman wrote: post #81

Earlier quoted context omitted.

I can never remember what they are, though. To avoid this problem, I think I wrote them down on a post-it, but I had too many post-its on my desk so I got rid of them all, and now I can't remember.

> wrote them down on a post-it You write it on local media and kept it on-premises? Cloud is the new thing, I hear.

The Post-it was but a cache.

Re: Git: Malicious repositories can execute remote code while cloning

#109

Post by krick »

caslon wrote: post #41

> This vulnerability affects platforms with case-insensitive filesystems with support for symbolic links, when certain clean/smudge filters are configured globally (e.g. Git LFS). Can we get the title changed to "on macOS and Windows?" I was worried for a second, but this is meaningless.

Yep, I sensed a similar relaxation when reading this. But whatever, don't be silly, title it long enough as it is.

Anyway, what I'm actually thinking when something like this is disclosed is how many more similar things must be known to a team of malicious professionals at Unit 8200 or whatever. I don't think I would reasonably suspect "git clone" being capable of something like that. How many more things I don't suspect to be dangerous actually are? It feels almost pointless to worry about it.

Re: Git: Malicious repositories can execute remote code while cloning

#110

Post by krick »

yjftsjthsd-h wrote: post #92
mateo411 wrote: post #72

I guess I'll have to stop running $ sudo git clone ...

I mean, there are... not-totally-unreasonable workflows that do clones as root. Edit: although I am struggling to think of one that clones from an untrusted source.

> not-totally-unreasonable workflows that do clones as root

Uh... really? Like what?

Post reply on HN