Comment by armchairhacker
6 days ago
> 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.
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.
9 replies →
Yes, unfortunately it's pretty trivial. Any time arbitrary file write is possible, RCE is usually possible too.
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?
I've adjusted that paragraph to make it more clear how writing a file can lead to code execution.
[flagged]
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.
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?)
4 replies →
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.