Securing Developer Tools: Git Integrations

by

Author: Thomas Chauchefoin (Vulnerability Researcher, Sonar)
Published: March 15, 2022
Source: https://www.sonarsource.com/blog/securing-developer-tools-git-integrations/

Summary

Sonar’s research team showed how a malicious Git repository can achieve arbitrary code execution simply by being opened in a developer tool or navigated to in a terminal. The trick abuses Git’s per-repository .git/config and its core.fsmonitor directive, which Git runs as an external command. Tools that automatically invoke Git (IDEs, shell prompts) trigger the attacker’s command before the user grants any trust. The findings led to fixes including CVE-2021-43891 (Visual Studio Code) and CVE-2022-24346 (JetBrains IDEs).

Technical Details

Git reads configuration from three levels — system, global, and repository-local — with the local .git/config taking precedence. Among the directives Git honors is core.fsmonitor, which the documentation describes as “a command which will identify all files that may have changed since the requested date/time.” Git executes that value as an external command whenever it needs to scan the working tree, for example during git status or git diff.

Because .git/config lives inside the repository directory, an attacker can ship a crafted config in any repository that a victim obtains outside of a normal clone — typically a downloaded or extracted archive. A minimal proof of concept sets:

[core]
    fsmonitor = "id>/tmp/fsmonitor"

Running git status in that directory then executes the injected command. The research notes that a normal git clone does not fetch a remote repository’s .git contents in a way that enables this, so the vector is specifically folders delivered as archives or downloads.

The danger is that many tools run Git automatically, before any trust decision. The official Git shell prompt script (contrib/completion/git-prompt.sh) exposes __git_ps1; when GIT_PS1_SHOWDIRTYSTATE=1 is set, merely cd-ing into the directory causes the prompt to run git diff, firing the core.fsmonitor command without consent. This affected the official Git prompt as well as integrations in Oh My Zsh and fish. In Visual Studio Code, the built-in Git extension declared support for untrusted workspaces, so it executed commands such as git rev-parse --show-toplevel, git rev-parse --git-dir, and git status -z -u immediately on opening a folder — before the Workspace Trust prompt appeared — again triggering the payload.

Impact

Successful exploitation yields arbitrary command execution in the context of the developer’s user account, simply by opening or entering a malicious folder — no explicit user action beyond that is required. On a developer workstation this means full user-level compromise, and because developers handle and redistribute code, it creates a realistic path toward supply-chain attacks. Affected software includes Visual Studio Code prior to 1.63.1 (CVE-2021-43891), JetBrains IDEs prior to 2021.3.1 (CVE-2022-24346), GitHub’s Atom editor (treated as outside its threat model, not fixed), and Git terminal prompt integrations.

Mitigation

Vendors addressed the issue by gating Git execution behind trust prompts: Visual Studio Code 1.63.2 and later moved the Git extension behind Workspace Trust, and JetBrains IntelliJ 2021.3.1 and later broadened its Trusted Projects support. Atom received no fix. The Git maintainers concluded that “there will always be potentially dangerous features in Git via this attack vector” and favored adjusting user security expectations over changing Git itself. Practical defenses recommended in the writeup include: disabling SCM/dirty-state prompts when handling untrusted code, keeping editors updated, opening third-party source inside disposable virtual machines, restricting CI/CD access to approved repositories, and disabling unsafe hooks in untrusted repositories.

References

Leave a Comment