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

81–90 of 302 posts

Re: Git security vulnerability announced

#81

Post by tedunangst »

omegalulw wrote: post #76
saagarjha wrote: post #59

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…

Their solution sounds reasonable. I don't particularly get why this is even a new vulnerability? If someone manages to create a .git at the root, that means the whole filesystem is under version control and appropriate hooks should execute. Why would this be surprising behavior now? In any "multi user system" as the article says, this would need root access and such a user can do many other bad things if their intent…

I can run git init in /tmp.

Re: Git security vulnerability announced

#82

Post by tylersmith »

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.

Re: Git security vulnerability announced

#83

Post by isatty »

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…

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

Re: Git security vulnerability announced

#84

Post by hda2 »

dhzhzjsbevs wrote: post #74
tedunangst wrote: post #68

Earlier quoted context omitted.

In earlier news, it's unexpected that "cd directory" will give the directory owner access to your account.

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?

Re: Git security vulnerability announced

#85

Post by krick »

dang wrote: post #66
carlosdp wrote: post #19

Earlier quoted context omitted.

This article on a CVE for git published today has details on the vulnerability: https://github.blog/2022-04-12-git-security-vulnerability-an...

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.

Re: Git security vulnerability announced

#86

Post by hadlock »

hadlock wrote: post #29
geoffeg wrote: post #4

Earlier quoted context omitted.

I'm guessing the goal is to lock down git's security for any potential future vulnerability. If some security issue was discovered with git that could be exploited with a malicious .git directory structure, requiring git directories to be owned by the logged-in user will reduce the impact.

Or, an exploit was discovered, and quietly patched out recently

Oh, there it is: https://github.blog/2022-04-12-git-security-vulnerability-an...

Re: Git security vulnerability announced

#87

Post by hda2 »

tedunangst wrote: post #81
omegalulw wrote: post #76

Earlier quoted context omitted.

Their solution sounds reasonable. I don't particularly get why this is even a new vulnerability? If someone manages to create a .git at the root, that means the whole filesystem is under version control and appropriate hooks should execute. Why would this be surprising behavior now? In any "multi user system" as the article says, this would need root access and such a user can do many other bad things if their intent…

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.

Re: Git security vulnerability announced

#89

Post by db48x »

Matheus28 wrote: post #71
db48x wrote: post #52

Earlier quoted context omitted.

Right, all that does is turn paths like ~/foo into /home/ /foo. I’ve no idea why it even takes the key as an argument.

It's so it can print an error referring to the key if there was a problem parsing.

Oh, that makes sense.

Re: Git security vulnerability announced

#90

Post by mlindner »

dang wrote: post #66
carlosdp wrote: post #19

Earlier quoted context omitted.

This article on a CVE for git published today has details on the vulnerability: https://github.blog/2022-04-12-git-security-vulnerability-an...

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

Ah ok this was the real link. The top level link to github.blog doesn't seem to have anything that this link here has. Please change it back.
Post reply on HN