9 ms·

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

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

geoffeg 5y ago
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.
- hadlock 5y ago
  Or, an exploit was discovered, and quietly patched out recently
  - hadlock 5y ago
    Oh, there it is: https://github.blog/2022-04-12-git-security-vulnerability-announced/ https://github.blog/2022-04-12-git-security-vulnerability-an...
    - hadlock 5y ago
      Replying to myself again, apparently the thread title changed from "hey git won't let you do this thing anymore" to "here's the CVE", and changed the link too. sorry for the confusion
tedunangst 5y ago
.git/config sets fsmonitor to malware.exe and boom.
- hsbauauvhabzb 5y ago
  Can you do this to a GitHub hosted repo?
  - oauea 5y ago
    No, the .git directory is not cloned. But if the repo is already on disk it can be game over.
    - ddworken 5y ago
      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-explained-bug-3/ https://offensi.com/2019/12/16/4-google-cloud-shell-bugs-exp...
      - megous 5y ago
        Looks like git complains of invalid paths when you try that.
        hsbauauvhabzb 5y ago
        Just because the cli won’t add doesn’t mean it may not be possible.
        nybble41 5y ago
        I was able to manually construct a commit with a .git subdirectory using `git mktree` and `git commit-tree`, but Git still refused to create the .git subdirectory in the index or working copy: [testrepo]$ git checkout --orphan test-branch [testrepo]$ git update-ref HEAD f4da9cde406a7b80d99694b5f8d369a8dd6e5a7d [testrepo]$ git ls-tree -r HEAD 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/.git/config [testrepo]$ git show commit f4da9cde406a7b80d99694b5f8d369a8dd6e5a7d (HEAD -> test-branch) Author: <<redacted>> Date: <<redacted>> WIP2 diff --git a/a/.git/config b/a/.git/config new file mode 100644 index 0000000..e69de29 [testrepo]$ git status On branch test-branch Changes to be committed: (use "git restore --staged <file>..." to unstage) deleted: a/.git/config [testrepo]$ git restore --staged a/.git/config error: invalid path 'a/.git/config' error: pathspec 'a/.git/config' did not match any file(s) known to git [testrepo]$ git reset --hard HEAD error: invalid path 'a/.git/config' fatal: Could not reset index file to revision 'HEAD'. So it looks like even if you do try to check out a tree with an unexpected .git subdirectory it won't actually be created in the filesystem.
GauntletWizard 5y ago
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 project. The next step is just to keep doing a pull/push cycle on every commit, but it's a bit more of a pain to make that happen.
- sodality2 5y ago
  https://git-scm.com/docs/git-config/2.35.2#Documentation/git-config.txt-safedirectory https://git-scm.com/docs/git-config/2.35.2#Documentation/git...
- bolangi 5y ago
  > 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.
carlosdp 5y ago
This article on a CVE for git published today has details on the vulnerability: https://github.blog/2022-04-12-git-security-vulnerability-announced/ https://github.blog/2022-04-12-git-security-vulnerability-an...
- dang 5y ago
  Ok, we've changed to that from https://github.com/git/git/commit/8959555cee7ec045958f9b6dd62e541affb7e7d9 https://github.com/git/git/commit/8959555cee7ec045958f9b6dd6.... Thanks!
  - delsarto 5y ago
    I feel like title doesn't really focus on the specific behaviour change (not operating in a non-owned directories) that will be affecting a lot of CI/CD, which is what I was interesting in seeing discussion on.
  - krick 5y ago
    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.
    - pvg 5y ago
      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.
      - Dylan16807 5y ago
        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?
ghewgill 5y ago
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 will pick up and call/run, even on simple operations like displaying the prompt.
- calvinmorrison 5y ago
  in other news, access to a users account gives them access to a users account
  - tedunangst 5y ago
    In earlier news, it's unexpected that "cd directory" will give the directory owner access to your account.
    - dhzhzjsbevs 5y ago
      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.
      - hda2 5y ago
        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?
        edgyquant 5y ago
        On my current app we use husky which installs hooks when you do a yarn install
teruakohatu 5y ago
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?
- Too 5y ago
  core.fsconfig is supposed to be read only, but since it’s an external process, git doesn’t know what really happens in there, so it can’t propagate any —-readonly enforcement.
  - leni536 5y ago
    That's where some sandboxing could help, maybe.

geoffeg 5y ago

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.

hadlock 5y ago
Or, an exploit was discovered, and quietly patched out recently
- hadlock 5y ago
  Oh, there it is: https://github.blog/2022-04-12-git-security-vulnerability-announced/ https://github.blog/2022-04-12-git-security-vulnerability-an...
  - hadlock 5y ago
    Replying to myself again, apparently the thread title changed from "hey git won't let you do this thing anymore" to "here's the CVE", and changed the link too. sorry for the confusion

tedunangst 5y ago

.git/config sets fsmonitor to malware.exe and boom.

hsbauauvhabzb 5y ago
Can you do this to a GitHub hosted repo?
- oauea 5y ago
  No, the .git directory is not cloned. But if the repo is already on disk it can be game over.
  - ddworken 5y ago
    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-explained-bug-3/ https://offensi.com/2019/12/16/4-google-cloud-shell-bugs-exp...
    - megous 5y ago
      Looks like git complains of invalid paths when you try that.
      - hsbauauvhabzb 5y ago
        Just because the cli won’t add doesn’t mean it may not be possible.
        nybble41 5y ago
        I was able to manually construct a commit with a .git subdirectory using `git mktree` and `git commit-tree`, but Git still refused to create the .git subdirectory in the index or working copy: [testrepo]$ git checkout --orphan test-branch [testrepo]$ git update-ref HEAD f4da9cde406a7b80d99694b5f8d369a8dd6e5a7d [testrepo]$ git ls-tree -r HEAD 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/.git/config [testrepo]$ git show commit f4da9cde406a7b80d99694b5f8d369a8dd6e5a7d (HEAD -> test-branch) Author: <<redacted>> Date: <<redacted>> WIP2 diff --git a/a/.git/config b/a/.git/config new file mode 100644 index 0000000..e69de29 [testrepo]$ git status On branch test-branch Changes to be committed: (use "git restore --staged <file>..." to unstage) deleted: a/.git/config [testrepo]$ git restore --staged a/.git/config error: invalid path 'a/.git/config' error: pathspec 'a/.git/config' did not match any file(s) known to git [testrepo]$ git reset --hard HEAD error: invalid path 'a/.git/config' fatal: Could not reset index file to revision 'HEAD'. So it looks like even if you do try to check out a tree with an unexpected .git subdirectory it won't actually be created in the filesystem.

GauntletWizard 5y ago

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 project. The next step is just to keep doing a pull/push cycle on every commit, but it's a bit more of a pain to make that happen.

sodality2 5y ago
https://git-scm.com/docs/git-config/2.35.2#Documentation/git-config.txt-safedirectory https://git-scm.com/docs/git-config/2.35.2#Documentation/git...
bolangi 5y ago
> 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.

carlosdp 5y ago

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

dang 5y ago
Ok, we've changed to that from https://github.com/git/git/commit/8959555cee7ec045958f9b6dd62e541affb7e7d9 https://github.com/git/git/commit/8959555cee7ec045958f9b6dd6.... Thanks!
- delsarto 5y ago
  I feel like title doesn't really focus on the specific behaviour change (not operating in a non-owned directories) that will be affecting a lot of CI/CD, which is what I was interesting in seeing discussion on.
- krick 5y ago
  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.
  - pvg 5y ago
    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.
    - Dylan16807 5y ago
      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?

ghewgill 5y ago

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 will pick up and call/run, even on simple operations like displaying the prompt.

calvinmorrison 5y ago
in other news, access to a users account gives them access to a users account
- tedunangst 5y ago
  In earlier news, it's unexpected that "cd directory" will give the directory owner access to your account.
  - dhzhzjsbevs 5y ago
    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.
    - hda2 5y ago
      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?
      - edgyquant 5y ago
        On my current app we use husky which installs hooks when you do a yarn install

teruakohatu 5y ago

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?

Too 5y ago
core.fsconfig is supposed to be read only, but since it’s an external process, git doesn’t know what really happens in there, so it can’t propagate any —-readonly enforcement.
- leni536 5y ago
  That's where some sandboxing could help, maybe.