Update to the latest version now, say developers
The Git Project has patched a vulnerability that could result in remote code execution.
The bug – tracked as CVE-2021-21300 – is present in several versions of the open source code management system, and could allow a hostile remote repository to execute code locally during a clone operation.
Crucially, the vulnerability only affects users with case-insensitive filesystems that enable support for symbolic links. Files using a clean/smudge filter such as Git LFS must also be enabled for the attack to work.
Read more of the latest remote code execution news
An announcement released yesterday (March 9) reads: “On case-insensitive file systems with support for symbolic links, if Git is configured globally to apply delay-capable clean/smudge filters (such as Git LFS), Git could be fooled into running remote code during a clone.”
A security advisory reads: “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 users are urged to update as soon as possible. The release fixes the bug in versions 2.17.6 through to 2.30.2.
Copycat problems
Git users often clone an existing repository for various reasons, such as building on a fully fledged copy from elsewhere or keeping a copy of their project in case the server disk is corrupted.
Since the RCE vulnerability only affects case-insensitive filesystems, not all Git users are vulnerable to exploitation.
MacOS – which enabled case-insensitive filesystems by default – is particularly open to attack, multiple sources have warned, as is Windows, which configures Git LFS by default.
READ Git developers release test code to transition away from aging SHA-1 hashing
“As a workaround, 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 advisory reads.
Other operating systems such as Linux – which is case-sensitive by default – are presumed to be safe, however users should still heed caution.
“This vulnerability affects case-insensitive file systems, therefore typical Linux scenarios should be safe,” wrote Red Hat software engineer Huzaifa Sidhpurwala.
“However as per upstream exploitation is even possible on Linux under certain circumstances.”
Improving user safety
Git was created back in 2005 by Linus Torvalds as a system to track changes in source code for the Linux kernel.
In recent years, it has undergone major changes including moving away from the aging SHA-1 hashing algorithm to a more secure alternative.
However, moving to a stronger hash has proved to be a tricky migration since in the early days of Git, Torvalds was “unconcerned about the possibility of SHA‑1 being broken”, and therefore he never designed in the ability to switch to a different hash.
YOU MAY ALSO LIKE Git security: Newline injection bug tricked version control system into leaking usernames and password
