Comment by beala
6 days ago
More information here (https://github.blog/open-source/git/git-security-vulnerabili...) on the new CVE:
> 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?
This seems easy for GitHub to block
It's not sufficient for GitHub to block it; plenty of Git repositories don't have anything to do with GitHub.
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
7 replies →