11 ms·

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 ofte

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
        eru 5y ago
        You are in luck, it seems: https://blog.typicode.com/husky-git-hooks-autoinstall/ https://blog.typicode.com/husky-git-hooks-autoinstall/ (Though not completely sure.)
      - Groxx 5y ago
        Just to react to: >Wait, I thought git hooks aren't pulled from remote. You are correct. They are not. Other tools may auto-install them (I hate it), but git does not ever.
- hsbauauvhabzb 5y ago
  This is really dismissive. Unexpected execution is not a users fault, and can happen for a variety of reasons (you telling me you’ve never unzipped a full git path someone sent you?)
  - seba_dos1 5y ago
    No? Why would someone zip me a git repo? You can clone/push/pull directly between machines.
    - nybble41 5y ago
      The source machine may not be set up as a server, or you may not have an account there. Sending a .zip file could be simpler than pushing the repo to a third system the receiver does have access to.
      - seba_dos1 5y ago
        Sure, mailing binaries can also be the right thing sometimes, but just as with git repos, you definitely shouldn't be taking them from untrusted sources. (and I bet that many people don't even realize how easy using `git push` to mirror a repo actually is, since git is very commonly used in a centralized fashion)
    - hsbauauvhabzb 5y ago
      You’ve never unzipped a repo? That’s something I regularly do - clients can’t get me access to their scm, and it’s not worth the effort.
      - seba_dos1 5y ago
        I don't think I ever did. I usually have an opposite problem and sometimes accidentally zip/tar a repo when it shouldn't be included (at least there's `--exclude-vcs`). In any case, this doesn't sound like a good idea at all, as git hooks exist.
isatty 5y ago
What do you mean by “git often installs”. Git does not install anything. Developers configure their PS1 or install something that does.
- gruez 5y ago
  on windows the default git package (ie. git bash) installs a bash terminal that has the git PS1 enabled.
- edgyquant 5y ago
  The default shell on Mac and a lot of Linux distros do this installation, as well as git for windows.
  - asvitkine 5y ago
    Can you explain? A shell isn't supposed to be installing things on it's own... (Assuming you're talking about zsh or bash when you say shell.)
    - loa_in_ 5y ago
      Yeah, even zsh doesn't do this by default
    - jyrkesh 5y ago
      There's a lot of different ways to install Git on a lot of different OSes, and some of them put helper shell scripts down by default.
      - Sharparam 5y ago
        That isn't Git installing things though, that is third-party Git distributions bundling things along with Git.
        jyrkesh 5y ago
        I'm aware, which is why I phrased it like I did. A lot of folks don't know or understand the distinction when they're installing Git (or installing something else that happens to bring Git with it). The overarching point is that the shell itself is not installing anything at shell runtime. E.g. it's the Git Bash installer, not opening `bash`.
eminence32 5y ago
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.
- gumby 5y ago
  > …PS1 script… That’s where you should have been concerned. Just typing a bare return will run some arbitrary code, as you, wherever you might be in the filesystem. If all of that isn’t under your control, someone can do anything to you.
jcranberry 5y ago
Damn. So the script I use to put the branch name in my prompt is bad? Could I solve this by making .git/config readonly for non sudo?
- WorldMaker 5y ago
  The concern here is more on `sudo vi /.git/config` than `sudo vi ~/.git/config`. Someone adding a "root" git config that you don't expect/intend to exist. If you think things are locked down strongly enough with sudo and never install anything that might add root files you don't expect you are most likely safe. This release also adds an environment variable you can set that makes certain that git has a "ceiling" that it never crosses when checking for .git/config files. The idea being that you'd never want git to look above `/user/*/` for instance, as you'd never expect to have a "machine-wide" git config.

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
      - eru 5y ago
        You are in luck, it seems: https://blog.typicode.com/husky-git-hooks-autoinstall/ https://blog.typicode.com/husky-git-hooks-autoinstall/ (Though not completely sure.)
    - Groxx 5y ago
      Just to react to: >Wait, I thought git hooks aren't pulled from remote. You are correct. They are not. Other tools may auto-install them (I hate it), but git does not ever.
hsbauauvhabzb 5y ago
This is really dismissive. Unexpected execution is not a users fault, and can happen for a variety of reasons (you telling me you’ve never unzipped a full git path someone sent you?)
- seba_dos1 5y ago
  No? Why would someone zip me a git repo? You can clone/push/pull directly between machines.
  - nybble41 5y ago
    The source machine may not be set up as a server, or you may not have an account there. Sending a .zip file could be simpler than pushing the repo to a third system the receiver does have access to.
    - seba_dos1 5y ago
      Sure, mailing binaries can also be the right thing sometimes, but just as with git repos, you definitely shouldn't be taking them from untrusted sources. (and I bet that many people don't even realize how easy using `git push` to mirror a repo actually is, since git is very commonly used in a centralized fashion)
  - hsbauauvhabzb 5y ago
    You’ve never unzipped a repo? That’s something I regularly do - clients can’t get me access to their scm, and it’s not worth the effort.
    - seba_dos1 5y ago
      I don't think I ever did. I usually have an opposite problem and sometimes accidentally zip/tar a repo when it shouldn't be included (at least there's `--exclude-vcs`). In any case, this doesn't sound like a good idea at all, as git hooks exist.

isatty 5y ago

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

gruez 5y ago
on windows the default git package (ie. git bash) installs a bash terminal that has the git PS1 enabled.
edgyquant 5y ago
The default shell on Mac and a lot of Linux distros do this installation, as well as git for windows.
- asvitkine 5y ago
  Can you explain? A shell isn't supposed to be installing things on it's own... (Assuming you're talking about zsh or bash when you say shell.)
  - loa_in_ 5y ago
    Yeah, even zsh doesn't do this by default
  - jyrkesh 5y ago
    There's a lot of different ways to install Git on a lot of different OSes, and some of them put helper shell scripts down by default.
    - Sharparam 5y ago
      That isn't Git installing things though, that is third-party Git distributions bundling things along with Git.
      - jyrkesh 5y ago
        I'm aware, which is why I phrased it like I did. A lot of folks don't know or understand the distinction when they're installing Git (or installing something else that happens to bring Git with it). The overarching point is that the shell itself is not installing anything at shell runtime. E.g. it's the Git Bash installer, not opening `bash`.

eminence32 5y ago

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.

gumby 5y ago
> …PS1 script… That’s where you should have been concerned. Just typing a bare return will run some arbitrary code, as you, wherever you might be in the filesystem. If all of that isn’t under your control, someone can do anything to you.

jcranberry 5y ago

Damn. So the script I use to put the branch name in my prompt is bad? Could I solve this by making .git/config readonly for non sudo?

WorldMaker 5y ago
The concern here is more on `sudo vi /.git/config` than `sudo vi ~/.git/config`. Someone adding a "root" git config that you don't expect/intend to exist. If you think things are locked down strongly enough with sudo and never install anything that might add root files you don't expect you are most likely safe. This release also adds an environment variable you can set that makes certain that git has a "ceiling" that it never crosses when checking for .git/config files. The idea being that you'd never want git to look above `/user/*/` for instance, as you'd never expect to have a "machine-wide" git config.