Moderate
CVE-2021-21300
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below:
Add References:
CVE-2021-21300
MITRE ATT&CK
Collection
Command and Control
Credential Access
Defense Evasion
Discovery
Execution
Exfiltration
Impact
Initial Access
Lateral Movement
Persistence
Privilege Escalation
Topic Tags
Description
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.
Add Assessment
Ratings
-
Attacker ValueMedium
-
ExploitabilityMedium
Technical Analysis
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.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportCVSS V3 Severity and Metrics
General Information
Vendors
- apple,
- debian,
- fedoraproject,
- git-scm
Products
- debian linux 10.0,
- fedora 32,
- fedora 33,
- fedora 34,
- git,
- git 2.27.0,
- git 2.28.0,
- xcode
References
Advisory
Miscellaneous
Additional Info
Technical Analysis
Report as Emergent Threat Response
Report as Exploited in the Wild
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below:
That’s incorrect.
@jermainlaforce Comments welcome but just stating its incorrect doesn’t help anyone; mind explaining why you think its incorrect? We welcome healthy debates :)