Git LFS vulnerability allows attackers to compromise targets’ Windows systems (CVE-2020-27955)

A critical vulnerability (CVE-2020-27955) in Git Large File Storage (Git LFS), an open source Git extension for versioning large files, allows attackers to achieve remote code execution if the Windows-using victim is tricked into cloning the attacker’s malicious repository using a vulnerable Git version control tool, security researcher Dawid Golunski has discovered.

CVE-2020-27955

It can be exploited in a variety of popular Git clients in their default configuration – GitHub CLI, GitHub Desktop, SmartGit, SourceTree, GitKraken, Visual Studio Code, etc. – and likely other clients/development IDEs (i.e., those install git with the Git LFS extension by default).

“Web applications / hosted repositories running on Windows which allow users to import their repositories from a URL may also be exposed to this vulnerability,” Golunski added.

About the vulnerability (CVE-2020-27955)

Golunski found that Git LFS does not specify a full path to git binary when executing a new git process via a specific exec.Command() function.

“As the exec.Command() implementation on Windows systems include the current directory, attackers may be able to plant a backdoor in a malicious repository by simply adding an executable file named: git.bat, git.exe, git.cmd or any other extension that is used on the victim’s system (PATHEXT environment dependent), in the main repo’s directory. As a result, the malicious git binary planted in this way will get executed instead of the original git binary located in a trusted path,” he explained.

The vulnerability can be triggered if the victim is tricked into cloning the attacker’s malicious repository using a vulnerable Git version control tool.

Golunski says that CVE-2020-27955 is trivial to exploit, and has released PoC exploit code, as well as video demonstrations of the exploit in action on various Git clients.

What to do?

The vulnerability affects Git LFS versions 2.12 or earlier on Windows systems (but not on Unix). According to the Git LFS maintainers, there is no workaround for this issue other than avoiding untrusted repositories.

Affected users and product vendors are advised to update to the latest Git LFS version (v2.12.1, released on Wednesday), which plugged the security hole. Git for Windows has also been updated to include this Git LFS version.

Don't miss