Git for Windows issues update to fix running-someone-else’s-code vuln

Running a multi-user Windows environment and Git? Time to patch

After a hefty Patch Tuesday comes news of an update for Git to deal with a vulnerability for the source shack when run on Microsoft's Windows.

A variety of releases were emitted by the team. These include the latest maintenance release, 2.35.2, along with updates for older maintenance tracks (v2.30.3, v2.31.2, v2.32.1, v2.33.2, and v2.34.2.)

The update is solely concerned with CVE-2022-24765, an interesting bug which afflicts the Git for Windows fork of Git. The vulnerability affects multi-user hardware where untrusted parties have write access to the same hard disk.

Arguably, if an "untrusted party" has write access to a hard disk, then all bets are off when it comes to the nooks and crannies of a PC anyway.

In this case, the miscreants would only need to create the folder c:\.git, "which would be picked up by Git operations run supposedly outside a repository while searching for a Git directory," according to NIST.

The result is that Git would use the config in the directory.

NIST went on to list potentially vulnerable products, which included Visual Studio. "Users of the Microsoft fork of Git are vulnerable simply by starting a Git Bash."

The Git team was little blunter about the vulnerability, and warned that "Merely having a Git-aware prompt that runs 'git status' (or 'git diff') and navigating to a directory which is supposedly not a Git worktree, or opening such a directory in an editor or IDE such as VS Code or Atom, will potentially run commands defined by that other user."

Not nice, but also very specific in terms of affected systems. These need to be multi-user machines, likely running Windows (probably due to how the file system of the OS works.) Ultimately, it is an arbitrary code issue, if one that requires access to the disk to implement.

To deal with the issue, the Git team recommends an update. Alternatively, a user could create that .git folder themselves and remove read/write access as workaround or "define or extend 'GIT_CEILING_DIRECTORIES' to cover the parent directory of the user profile," according to NIST.

The code shack gave a hattip to 俞晨东 for finding the bug and Johannes Schindelin for working on a fix.

Ultimately, if you can, then patching seems the best way to go. As the Git team noted: "Please update at your earliest opportunity." ®