CVE-2021-21300

Git is an open-source distributed revision control system. In affected versions of Git a specially crafted repository that contains symbolic links as well as files using a clean/smudge filter such as Git LFS, may cause just-checked out script to be executed while cloning onto a case-insensitive file system such as NTFS, HFS+ or APFS (i.e. the default file systems on Windows and macOS). Note that clean/smudge filters have to be configured for that. Git for Windows configures Git LFS by default, and is therefore vulnerable. The problem has been patched in the versions published on Tuesday, March 9th, 2021. As a workaound, if symbolic link support is disabled in Git (e.g. via git config --global core.symlinks false), the described attack won’t work. Likewise, if no clean/smudge filters such as Git LFS are configured globally (i.e. before cloning), the attack is foiled. As always, it is best to avoid cloning repositories from untrusted sources. The earliest impacted version is 2.14.2. The fix versions are: 2.30.1, 2.29.3, 2.28.1, 2.27.1, 2.26.3, 2.25.5, 2.24.4, 2.23.4, 2.22.5, 2.21.4, 2.20.5, 2.19.6, 2.18.5, 2.17.62.17.6.

Recent assessments:

space-r7 at March 26, 2021 5:46pm UTC reported:

While this vulnerability has the potential to be dangerous, I think the limitations for exploitation outweigh its value. To successfully exploit this vulnerability, an attacker must be able to host a malicious repo and convince a user to clone said repo. Additionally, each platform has its own requirements.

There are a few hosting options, and they all have their caveats that would limit the exploit in some way. An attacker could use a “trusted” hosting service such as Github, Gitlab, etc. Hosting on a trusted service could be either through compromising an existing, perhaps commonly-used repo or by hosting a single, malicious repo of their own. The former option adds complexity because it would require the attacker to be able to add multiple files to the repo unnoticed. The latter option would be an easier and more credible / trustworthy option versus using a self-hosting method. Despite that, the repo would likely be identified and removed, limiting the exploit even further. As mentioned before, the self-hosting option exists, but would be the most limited since users would be more cautious with repositories from an untrusted source.

Aside from the hosting limitations, a user must have some form of clean / smudge filters set up globally with Git so that the repo’s contents can be checked out out-of-order on a clone. According to the advisory, Git for Windows has clean / smudge filters set up by default through Git-lfs, so Windows users are most vulnerable. For MacOS, clean / smudge filters must be set up manually. Thanks to Foone’s fantastic analysis, it turns out that Linux can also be vulnerable, provided that clean / smudge filters are set up globally, and the malicious repo is cloned on a case-insensitive file system, i.e., a mounted drive.

Because so many limitations exist for successful exploitation, I wouldn’t rate this as a critical vulnerability. It is dangerous, but because it relies on user interaction and a specific local configuration of the vulnerable software, I’m giving it a middle score for both Attacker Value and Exploitability. I’ve selected both vulnerable in default configuration and vulnerable in uncommon configuration since it’s dependent on the platform that the Git client is installed on. Windows is vulnerable by default, and the other platforms require additional setup to be truly vulnerable.

As always, upgrade to the patched version, especially Windows users in this case. If that’s not possible, users can still disable global clean / smudge filters and disable symlinks in Git.

Assessed Attacker Value: 3
Assessed Attacker Value: 3Assessed Attacker Value: 3