> When reading a configuration value, Git will strip any trailing carriage return (CR) and line feed (LF) characters. When writing a configuration value, however, Git does not quote trailing CR characters, causing them to be lost when they are read later on. When initializing a submodule whose path contains a trailing CR character, the stripped path is used, causing the submodule to be checked out in the wrong place.
> If a symlink already exists between the stripped path and the submodule’s hooks directory, an attacker can execute arbitrary code through the submodule’s post-checkout hook.
Along with a bunch of other git CVEs that are worth a look.
So in order to invoke foreign code the attacker must first write into a shell script located under A/.git/hooks, where A is missing the CR as opposed to the original path? I think when you can write shell scripts to .git/hooks it is already game over, no?
Submodules can be any URL (and recursive), so for GitHub to block this totally would require them to crawl other forges (and some URLs could be private URLs, but GitHub likely can't tell that apart from an attacker who is just blocking GitHub). So the risk is GitHub could say they are blocking this and give a false sense of security.
Some previous bugs have resulted in validation added to git fsck, but because clone URLs can't change after the submodules are initialised that's not going to have any benefit here. (There were some defence-in-depth measures discussed, there's definitely a few things that can be improved here.)
You can always find edge cases in security. Someone somewhere is running Internet Explorer 10 but that doesn't mean Chrome fixing bugs doesn't dramatically reduce effectiveness of attacks
Describing people using Git without GitHub as an "edge case" is arrant nonsense. Git was developed for the Linux kernel, which isn't hosted on GitHub, though it has mirrors. Most corporate intranets, SourceForge, GitLab, Sourcehut, and probably most programmers' laptops have Git repositories that do not push to GitHub.
Those people won't be vulnerable to this attack, since this attack is only useful in supply chain attacks. The people vulnerable to this would be maintainers of open source repos who could end up approving a malicious PR.
You can certainly launch supply-chain attacks via SourceForge or GitLab; indeed, probably the most famous open-source supply-chain attack in history was carried out by SourceForge's former owners.
Just using git isn't the vulnerability. The vulnerability is that you clone a repo that an attacker was able to put this in. 90% of the time this would happen it would be due to an attacker creating a PR on a public repo.
> When reading a configuration value, Git will strip any trailing carriage return (CR) and line feed (LF) characters. When writing a configuration value, however, Git does not quote trailing CR characters, causing them to be lost when they are read later on. When initializing a submodule whose path contains a trailing CR character, the stripped path is used, causing the submodule to be checked out in the wrong place.
> If a symlink already exists between the stripped path and the submodule’s hooks directory, an attacker can execute arbitrary code through the submodule’s post-checkout hook.
Along with a bunch of other git CVEs that are worth a look.