Live data from Hacker News

Git security vulnerability announced

github.blog

101–110 of 302 posts

Re: Git security vulnerability announced

#101
post #43
post #34

Deep inside some large enterprise company: Jr Engineer: "Hey, I know we've always managed our little dotnet application via email and shared-network-drive, but I've been reading about a thing called "git" that we should probably use." Sr Engineer: "Change is scary and bad, also we are not a software company. We're not going to learn some newfangled whatsit. Just email me the .vba files when you want me to review the…

The premise of this story is one I lived. I was a web dev intern for a local government office and they actually emailed each other zips of dotnet apps. The only difference is that my git pitch went really well and they promised they would start using it. They never started using it.

Local government software dev is making half of what they could make doing barely anything at a private sector operation. Not surprising there’s an IQ problem.

Re: Git security vulnerability announced

#102
post #87

Earlier quoted context omitted.

I can run git init in /tmp.

Then don't run commands in PS1 that blindly execute arbitrary code in that directory. Honestly, people haven't learned a single thing from Window's autorun days.

I mean, I don't have git status in PS1 anyway, but I woke up today not knowing that git status will run arbitrary commands. The documentation for git-status does not mention this possibility, like git-commit and git-pull do.

Re: Git security vulnerability announced

#103
post #87

Earlier quoted context omitted.

I can run git init in /tmp.

Then don't run commands in PS1 that blindly execute arbitrary code in that directory. Honestly, people haven't learned a single thing from Window's autorun days.

> Then don't run commands in PS1 that blindly execute arbitrary code in that directory.

That's like telling people "be secure". Nobody expected that git commands would do that, and also they shouldn't do that.

Not that I think this is a good fix...

Re: Git security vulnerability announced

#104

I shouldn’t ask too much of an open source project, etc. etc., but this sounds like something Git should fix themselves rather than just outright disabling. “I want to go into a directory and run git log” is kind of a simple thing to want to do and to not be able to do that sucks. It’s easy to pontificate on this forum but having a “safe” git that doesn’t automatically run hooks or whatever seems like the way forward…

[deleted]

Re: Git security vulnerability announced

#105

Earlier quoted context omitted.

Though you could have a repository on Github that contains a subdirectory that is a malicious bare Git repo. So doing: ``` git clone github.com/foo/bar cd bar/subdir/ ``` is unsafe with a Git PS1. See https://offensi.com/2019/12/16/4-google-cloud-shell-bugs-exp...

Or create a mercurial repo that contains a .git directory, and rely on finger memory making them run git immediately after cloning...

I’ve done that a few times. I’ve typed “git foo” while mentally thinking about “svn foo”, and after a few hours working on a project that still uses svn I will start making the opposite substitution too.

Re: Git security vulnerability announced

#106
post #75

Was this change discussed publicly prior to merge? I think this is a big mistake. Build environments use separate users for security purposes. It's insane to decrease security for everyone by requiring a single user to do everything because some of your users want to have fancy terminal prompts. At the very least, let users configure this at a per-user level.

Fixing RCE vulnerabilities isn't something that should be debated about publicly.

Nitpick: This isn't an RCE. An attacker would need 1) write access to a /local/ directory that the target will navigate to in his shell, and 2) convince the target to execute arbitrary git hooks in every directory (or parent directory) he visits by adding git to his shell's PS prompt.

Besides, now that this security issue is patched, git devs should seek a proper solution to that doesn't break git and decrease security for everyone else.

Re: Git security vulnerability announced

#108
post #85
post #66

Earlier quoted context omitted.

Ok, we've changed to that from https://github.com/git/git/commit/8959555cee7ec045958f9b6dd6... . Thanks!

You basically substituted both the link and the title to a completely different one after long time people discussing that specific link and title. Now half of the comments don't really make sense at the first glance.

The original link barely made any sense and many of those comments were comments without the useful context. The root cause here is the iffy submission, not the outdated comments or the change to a more meaningful link.

Re: Git security vulnerability announced

#110
post #83

Earlier quoted context omitted.

The key is the "Git-enabled `PS1`". PS1 is an environment variable recognised by common shell programs (such as bash) that configures the shell prompt. Git often installs its own glue into the prompt that ends up running a Git executable to discover such things as the current branch name and how many changed files. The vulnerability is that it's possible to add malicious things to .git/config that the git executable…

What do you mean by “git often installs”. Git does not install anything. Developers configure their PS1 or install something that does.

The default shell on Mac and a lot of Linux distros do this installation, as well as git for windows.
Post reply on HN