Hacker News Reader

Comment by beala | Hacker News Reader

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.

View on HN

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

Someone using git without github isn't an edge case, it's the default

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.

Many public repos aren't on GitHub.

Many people use IE 11. Still an edge case.

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.

Reply on news.ycombinator.com