Breaking Git with a carriage return and cloning RCE

> The result of all this, is when a submodule clone is performed, it might read one location from path = ..., but write out a different path that doesn’t end with the ^M.

How does this achieve “remote code execution” as the article states? How serious is it from a security perspective?

> I'm not sharing a PoC yet, but it is an almost trivial modification of an exploit for CVE-2024-32002. There is also a test in the commit fixing it that should give large hints.

EDIT: from the CVE-2024-32002

> Repositories with submodules can be crafted in a way that exploits a bug in Git whereby it can be fooled into writing files not into the submodule's worktree but into a .git/ directory. This allows writing a hook that will be executed while the clone operation is still running, giving the user no opportunity to inspect the code that is being executed.

So a repository can contain a malicious git hook. Normally git hooks aren’t installed by ‘git clone’, but this exploit allows one to, and a git hook can run during the clone operation.

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.

In this case, there is more than enough information given to make an exploit trivial for anyone actually investigating the issue. I don’t see a reason to distribute PoC exploit code here, it’s fairly clear what the problem is as well as at least one possible RCE implementation.

Yes, unfortunately it's pretty trivial. Any time arbitrary file write is possible, RCE is usually possible too.

This seems easy for GitHub to block

A well-written article should still have spelled out what armchairhacker did. The article spent many paragraphs working through what seemed to me like a very obvious chain of reasoning that didn't need so much hand-holding, and then left me completely bewildered at the end with the last step. And even with the explanation, I'm still not sure why writing the files to a different path allows the hook to be written. (Surely Git knows that it's still in the middle of a recursive clone operation and that it therefore shouldn't accept any hooks?)

Git does "know" that – but it doesn't know it's writing a hook.

I think what they're saying is it shouldn't execute any hooks during a first clone operation.

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.)

I've adjusted that paragraph to make it more clear how writing a file can lead to code execution.

There are hundreds of files on your system that if you could write to them would cause a RCE. For example, `AUTOEXEC.BAT`. While the intermediate step (how do you go from writing a filename without an ^M to writing to an arbitrary file on the target OS?) is also somewhat surprising (and maybe points at some potential deeper fixes within git or potential TOCTOU bugs?), ultimately it's the exact same as several other vulnerabilities in this class from the same author (see the 2024 case-sensitivity bug they linked), so I forgive them for glossing over it.

The exploit being trivial also removes any reason not to show a complete PoC.

There is no security impact for most people anyway as the next step after a git clone is usually to run some kind of build command which executes arbitrary code from the repo.

Git probably doesn't allow the submodule path to be .git but does allow .git\r which would then actually be written to .git due to the broken escaping.

Could this be mitigated by moving .git out of work tree directory and using unprivileged process that only has access to work tree directory to do all the file manipulation?

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?

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

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.