Live data from Hacker News

Git security vulnerability announced

github.blog

91–100 of 302 posts

Re: Git security vulnerability announced

#91
post #67
post #61

Earlier quoted context omitted.

I kindof agree with you, but if you go to a university lab then you will likely find that all the students are all in the same groups. You don’t really want to blindly trust the group that way.

Oh yeah, in such an environment that would not make sense. I'm saying it should be a (local/global) config option, not enabled by default. EDIT: Or maybe even more general, trustedOwnerUsers / trustedOwnerGroups

That’s a good idea; you should implement it and send them a patch.

Re: Git security vulnerability announced

#92
post #80

This is bullshit. I mean, ok, you are concerned about somebody using git-enabled PS1. Guess what, not everyone is using git-enabled PS1. Unbelievable, right? I would even mock the fact that you are trying to protect users from the behavior they pretty much explicitly allowed, but this is pointless. Truth is, developers are doing something that can fuck up their system daily. Let's forget about wget | bash and copying…

>Guess what, not everyone is using git-enabled PS1

not everyone is running on a multi-user system either (realistically speaking, most personal computers are single user). That doesn't mean microsoft/apple/linux doesn't care about escalation of privilege exploits.

>Truth is, developers are doing something that can fuck up their system daily. Let's forget about wget | bash and copying completely untrusted git repositories (and it's pretty much guaranteed that everybody using git-enabled PS1 won't shy away from that).

So because devs are doing dumb shit on a daily basis, they shouldn't fix security vulnerabilities? What if I'm not doing dumb shit? should I get hacked because I entered a malicious directory on a multi-user system?

>I mean, actually fixing: making it possible to disable hooks & core.fsmonitor & whatever else they fucked up? No, right, let's just disable git instead.

but then what if you need hooks? then you'll have to somehow manually enable it on a repo-by-repo basis, which also doesn't seem very convenient. At least with the ownership check it's transparent to most users. For people that use shared directories and/or network drive mounts, they can always whitelist the path.

Re: Git security vulnerability announced

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

on windows the default git package (ie. git bash) installs a bash terminal that has the git PS1 enabled.

Re: Git security vulnerability announced

#94

Did the link get changed? I can't find anything of what anyone is talking about in this github.blog post.

Yeah, dang updated the link: https://news.ycombinator.com/item?id=31010550 (it was previously https://github.com/git/git/commit/8959555cee7ec045958f9b6dd6...)

Re: Git security vulnerability announced

#96

> Merely navigating to such a space with a Git-enabled `PS1` when there is a maliciously-crafted `/scratch/.git/` can lead to a compromised account. I'm curious about this -- what's the attack vector here?

Repos can have precommit hooks, which are just executables (usually executable she'll scripts, but anything will do) that will run (as your user) on commit, checkout, etc. I feel like this change is a far bigger one than thought, and it's gonna break some workflows, such as mine where I have a git repo that's shared between multiple "users" that I run applications as. I'm glad I've not gotten too far into this projec…

> I feel like this change is a far bigger one than thought, and it's gonna break some workflows

Breaks the CI system for perl, for example.

Re: Git security vulnerability announced

#97
post #63

I feel like this doesn't have much to do with Git specifically. Seems to me like PS1 needs to avoid accessing files that aren't owned by the current user. Easier said than done though...

That’s partly true, but it is more relevant to Git than to other things because there are malicious ways to configure a git repository that will end up running programs written by someone else under your user id.

Why are you setting your ps1 to run arbitrary code in any directory? Don’t do that!

Re: Git security vulnerability announced

#98
post #7
post #2

Well, depending on exactly how much this blocks, this could get pretty awkward -- typing 'git log' in a repo owned by someone else can be awfully handy, even if file system permissions block changing it at all, and putting together a list of all places you might want to do this in advance could get pretty awkward. (Not running hooks, or allowing operations that would trigger them, from non-owned directories would pre…

Yes I’ve run “git status”, “git log” and “git diff” on other people’s repo’s plenty of times to help debug things, so it’d be sad to see this stop working. It seems some basic readonly operations should still be supported.

It doesn't even have to be a repo. I do git diff --no-index all the time on arbitrary files, because it's simply configured the way I want, unlike some default diff or whatever command, that I don't even remember how to properly use.

Re: Git security vulnerability announced

#100
post #63

Earlier quoted context omitted.

That’s partly true, but it is more relevant to Git than to other things because there are malicious ways to configure a git repository that will end up running programs written by someone else under your user id.

Why are you setting your ps1 to run arbitrary code in any directory? Don’t do that!

It’s one step more indirect than that. If I want my prompt to tell me what branch is checked out, I can have it include the output of running `git branch`, for example. Unbeknownst to me, running `git branch` can cause git to run programs specified in the git repository’s config file. It’s not normally a problem of course, because I am using my own computer with all of my own git repositories. But it can be a problem if the computer is shared with others.
Post reply on HN