←back to thread

Breaking Git with a carriage return and cloning RCE

(dgl.cx)
356 points dgl | 7 comments | 08 Jul 25 17:48 UTC | HN request time: 1.02s | source | bottom
Show context
armchairhacker ◴[08 Jul 25 18:32 UTC] No.44502705[source]▶
> 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.

replies(5): >>44502770 #>>44502837 #>>44502889 #>>44503715 #>>44505808 #
1. jmb99 ◴[08 Jul 25 20:07 UTC] No.44503579[source]▶
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.
replies(2): >>44504013 #>>44508189 #
2. zahlman ◴[08 Jul 25 20:58 UTC] No.44504013[source]▶
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?)
replies(3): >>44504464 #>>44505965 #>>44508198 #
3. wizzwizz4 ◴[08 Jul 25 22:02 UTC] No.44504464{3}[source]▶
Git does "know" that – but it doesn't know it's writing a hook.
replies(1): >>44504917 #
4. LoganDark ◴[08 Jul 25 23:23 UTC] No.44504917{4}[source]▶
I think what they're saying is it shouldn't execute any hooks during a first clone operation.
5. nightpool ◴[09 Jul 25 02:55 UTC] No.44505965{3}[source]▶
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.
6. account42 ◴[09 Jul 25 10:19 UTC] No.44508189[source]▶
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.

7. account42 ◴[09 Jul 25 10:21 UTC] No.44508198{3}[source]▶
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.