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

Git security vulnerability announced

github.blog

Post reply on HN
Print view View original

111–120 of 302 posts

Re: Git security vulnerability announced

#111

Post by wonnage »

tylersmith wrote: post #82
hda2 wrote: 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.

This isn't an RCE, you need to have control over the parent directory first which usually implies some sort of admin privileges already

Re: Git security vulnerability announced

#112

Post by eminence32 »

ghewgill wrote: post #33
eminence32 wrote: post #3

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

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…

Yeah, I'm familiar with PS1, but I was a bit surprised to learn that simple things that a PS1 script might do (git status, perhaps) are attack vectors. It seems that one big concern is the core.fsmonitor option (which I just learned about now). From the git-config man page:

> If set, the value of this variable is used as a command which will identify all files that may have changed since the requested date/time.

Re: Git security vulnerability announced

#113

Post by edgyquant »

hda2 wrote: post #84
dhzhzjsbevs wrote: post #74

Earlier quoted context omitted.

Tbh I thought this was pretty obvious. Git hooks have always been sketchy as hell. Can't stand the Mac specific shit my co-workers keep dumping in there.

Wait, I thought git hooks aren't pulled from remote. Wouldn't untrusted git hooks mean that git verify-* are useless since you're already running untrusted code?

On my current app we use husky which installs hooks when you do a yarn install

Re: Git security vulnerability announced

#114

Post by userbinator »

gruez wrote: post #92
krick wrote: 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 reposito…

That doesn't mean microsoft/apple/linux doesn't care about escalation of privilege exploits.

Because they're authoritarian control-freaks who want to take away even the concept of ownership eventually, having it all to themselves. They want to be able to force users into doing whatever they want.

If you're wondering "Linux too?" --- I'm not saying Linus himself is an enemy, nor a lot of the neutral developers who have contributed good things to it, but all the corporate interests (like Android --- via Google) have shoved plenty of "trusted" computing shit into the kernel, and "secure" boot for Linux distros is still ultimately controlled by a Microsoft key.

We are starting to wake up to this "security" bullshit.

Re: Git security vulnerability announced

#115

Post by Dylan16807 »

pvg wrote: post #108
krick wrote: post #85

Earlier quoted context omitted.

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.

The original title was "Git 2.30.3 will not operate in non-owned directories" which makes perfect sense to me, and the link provides a good explanation of the security problem. What barely makes any sense about it?

Re: Git security vulnerability announced

#117

Post by hda2 »

gruez wrote: post #92
krick wrote: 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 reposito…

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

What's wrong with that? Git hooks are inherently dangerous (i.e. running arbitrary code) and should be something you opt into manually.

Re: Git security vulnerability announced

#118

Post by ineptech »

wolfgang42 wrote: post #94
mlindner wrote: post #88

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

Thank you, I was confused. I'm very curious if the people complaining about this change as being too paternalistic still feel that way after reading the full disclosure link.

Re: Git security vulnerability announced

#119

Post by saagarjha »

hda2 wrote: post #87
tedunangst wrote: post #81

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.

This is kind of why I’d want a git command that doesn’t blindly execute arbitrary code from the directory, as I mentioned above.

Re: Git security vulnerability announced

#120

Post by comex »

tedunangst wrote: post #64
ddworken wrote: post #17

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

Finger memory, or just a shell configured to run `git status` before every command, as some people have.

And besides a Mercurial repo, it could also be a tarball or zip file…

Quite a dangerous situation.

Post reply on HN