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

61–70 of 302 posts

Re: Git security vulnerability announced

#61

Post by db48x »

3np wrote: post #28
rst wrote: 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…

Yeah, it does seem to be very limiting. The previous behavior of allowing it can be configured by safe.directory[0]. In lack of CI I still tend to do builds in a container from a separate local user with read-only permissions. I wish they'd add an option to allow it when the user is in the owner group, which could be a decent compromise. [0]: https://git-scm.com/docs/git-config/2.35.2#Documentation/git...

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.

Re: Git security vulnerability announced

#62

Post by teruakohatu »

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?

Couldn't that be mitigated by git adding a --readonly option that prevents any write operations? Then just use that option for any PS1 executables?

Re: Git security vulnerability announced

#63

Post by db48x »

dataflow wrote: post #46

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.

Re: Git security vulnerability announced

#64

Post by tedunangst »

ddworken wrote: post #17
oauea wrote: post #12

Earlier quoted context omitted.

No, the .git directory is not cloned. But if the repo is already on disk it can be game over.

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

Re: Git security vulnerability announced

#66

Post by dang »

carlosdp wrote: post #19
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?

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!

Re: Git security vulnerability announced

#67

Post by 3np »

db48x wrote: post #61
3np wrote: post #28

Earlier quoted context omitted.

Yeah, it does seem to be very limiting. The previous behavior of allowing it can be configured by safe.directory[0]. In lack of CI I still tend to do builds in a container from a separate local user with read-only permissions. I wish they'd add an option to allow it when the user is in the owner group, which could be a decent compromise. [0]: https://git-scm.com/docs/git-config/2.35.2#Documentation/git...

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

Re: Git security vulnerability announced

#68

Post by tedunangst »

calvinmorrison wrote: post #56
ghewgill wrote: post #33

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…

in other news, access to a users account gives them access to a users account

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

Re: Git security vulnerability announced

#69

Post by kadoban »

hsbauauvhabzb wrote: post #10

This is silly. Fix PS1, I can’t trust all repos I clone. I also want to cross-user access git log/blame etc.

You don't have to trust repos you clone, if I understand correctly. You just need to trust ones you're given in other ways. The difference is, clone won't let you set up arbitrary config (or malformed internal data or etc.)

Re: Git security vulnerability announced

#70

Post by db48x »

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…

On the one hand I agree with you; on the other hand that would entail enumerating all possible unsafe configurations. In general when designing a security measure you never want to try to enumerate everything that could be unsafe, because there is always an attacker who is more clever than you are who will think of something you left off the list.
Post reply on HN