Git-Sicherheitslücke bei Carriage Returns und Klonvorgängen mit RCE

• Einführung in eine Angriffstechnik mit Carriage-Return-Zeichen in Git-Repositories
• Diese Schwachstelle ermöglicht potenziell Remote Code Execution (RCE)
• Während eines bestimmten git clone-Ablaufs können bösartige Befehle ausgeführt werden
• Auswirkungen wurden in Linux- und Windows-Umgebungen bestätigt
• Hervorgehoben wird das Risiko einer unsicheren Verwaltung von Git-Repositories

---

Carriage-Return-Zeichen und eine Git-Sicherheitslücke

• Innerhalb eines Git-Repositories können Dateinamen mit Carriage-Return-Zeichen (\r) erzeugt werden
• Wird ein Repository mit solchen Dateinamen per git clone kopiert, kann es bei der Befehlsinterpretation zu unbeabsichtigter Befehlsausführung kommen

Szenario für Remote Code Execution (RCE)

• Ein Angreifer fügt dem Repository eine Datei hinzu, deren Name ein Carriage-Return-Zeichen enthält, und committet diese
• Wenn ein Benutzer dieses Repository per git clone klont, besteht durch Fehlinterpretationen im Dateisystem und in Git-Befehlen das Risiko einer unerwünschten Codeausführung
• Insbesondere kann die automatische Ausführung von Hook-Skripten (z. B. Code im Ordner .git/hooks) herbeigeführt werden

Betroffene Umgebungen und Gegenmaßnahmen

• Das Problem kann in Git unter verschiedenen Betriebssystemen wie Linux und Windows auftreten
• Für Entwickler und Unternehmen, die Git-Repositories verwalten oder häufig externe Repositories klonen, stellt dies eine ernsthafte Sicherheitsbedrohung dar

Sicherheitsempfehlungen

• Beim Klonen externer, nicht vertrauenswürdiger Git-Repositories sollten aktuelle Versionen verwendet und der Sicherheitsstatus geprüft werden
• Dateinamen mit ungewöhnlichen Zeichen im Repository (insbesondere Carriage Returns) sollten erkannt und vor dem Klonen überprüft werden

[GN⁺]

Hacker-News-Kommentar

• All das führt dazu, dass beim Klonen eines Submoduls beim Lesen path = ... verwendet wird, beim Schreiben aber in einen anderen Pfad geschrieben wird, der nicht auf ^M endet

  • Es wird die Frage aufgeworfen, wie genau aus dem im Artikel erwähnten „Remote Code Execution“ hier eintritt und wie gravierend das sicherheitstechnisch ist

  • Ein PoC wurde zwar noch nicht veröffentlicht, aber es heißt, es sei fast eine direkte Abwandlung des Exploits für CVE-2024-32002, und auch die Tests im fixenden Commit gäben starke Hinweise

  • Zitat aus der Beschreibung von CVE-2024-32002: Ein Repository mit Submodulen kann bösartig präpariert werden, sodass durch einen Git-Bug Dateien nicht in das Submodul-Worktree, sondern in das Verzeichnis .git/ geschrieben werden. Dadurch lassen sich Hooks platzieren, die schon während des Klonvorgangs ausgeführt werden, sodass der Nutzer nicht einmal Gelegenheit hat, den tatsächlich ausgeführten Code zu prüfen

  • Kurz gesagt: Man kann einen bösartigen Git-Hook in das Repository einschleusen. Normalerweise werden Git-Hooks bei git clone nicht installiert, aber dieser Angriff macht genau das möglich und eröffnet damit die Möglichkeit einer Hook-Ausführung während des Klonens

  • Weitere Informationen zur neuen CVE gibt es hier

    • Beim Lesen von Konfigurationswerten entfernt Git CR- und LF-Zeichen, beim Schreiben wird CR aber nicht maskiert, wodurch es beim Einlesen zu Informationsverlust kommt
    • Wenn am Ende eines Submodul-Pfads ein CR-Zeichen steht, wird der bereinigte Pfad verwendet, wodurch das Submodul möglicherweise an der falschen Stelle ausgecheckt wird
    • Falls zwischen diesem bereinigten Pfad und dem Hook-Verzeichnis des Submoduls bereits ein Symlink existiert, kann ein Angreifer über einen post-checkout-Hook beliebigen Code ausführen
    • Neben dieser CVE gebe es noch viele weitere Git-Schwachstellen, die ebenfalls einen Blick wert seien

  • Es wird die simple, aber unangenehme Wahrheit erwähnt, dass beliebiges Dateischreiben meist auch zu RCE führen kann

• Es wird auf die Risiken hingewiesen, Konfigurationsdateien mit einer ad-hoc-DSL zu schreiben

  • Oft gebe es keine formale Spezifikation der Grammatik, und der eigentliche Maßstab fürs Parsing sei über selbstgebaute Serialisierungs-/Deserialisierungsimplementierungen verteilt

  • Wenn beides auseinanderläuft, etwa weil der Parser neue Syntax unterstützt, der Writer aber nicht, könne die Differenz im Parsing zur Zeitbombe werden

  • Die Lehre daraus: Man brauche eine einzige source of truth, und alles, was davon abhängt, sollte auf dieser Basis automatisch erzeugt werden

  • Es wird darauf hingewiesen, dass dieser Bug vom source-of-truth-Problem getrennt zu betrachten ist

    • Es handle sich um einen reinen Logikfehler, der genauso in einer standardisierten Systembibliothek auf Unix hätte auftreten können, wenn es dort so etwas gäbe
    • Wäre er in so einer Standardbibliothek aufgetreten, wären die Auswirkungen deutlich schwerwiegender; so sei der Schaden vor allem auf Entwickler begrenzt und daher geringer

  • Die hier verwendete DSL, also das INI-Dateiformat, sei zwar ad hoc, aber so verbreitet und vertraut, dass sie im Allgemeinen als faktische Spezifikation ausreiche

    • Der Kern des Bugs liege nicht im Format, sondern in einem dazwischengeschalteten handgeschriebenen Parser (oder Lexer), und mit solcher Art Code sollte man inzwischen aufhören
    • Es gebe zwar noch einige Fälle, in denen clever handgeschriebene Parser nötig seien, aber für Datenaustauschformate sollten sie nie verwendet werden: Wenn man INI braucht, dann TOML, wenn das nicht passt, JSON, sogar YAML sei okay, wer wirklich Schmerzen suche, könne XML nehmen, und wer unbedingt ein Binärformat wolle, solle Protobufs nutzen
    • Fazit: Wenn man nicht gerade Programmiersprachen entwickelt, sollte man keinen Parser selbst schreiben, sondern unbedingt Bibliotheken verwenden

• Jemand hat das Problem selbst reproduziert und in dieses Repository hochgeladen

  • Es wird direkt versucht, auf die neueste Git-Version zu aktualisieren; für Arch sei das noch nicht verfügbar

  • Bis ein neuer Patch erscheint, wolle man pull eher vermeiden; bei bekannten Repositories mit automatischem Pull könne das problematisch werden, und es werde wohl dauern, bis überall aktualisiert ist

  • Es wird gefragt, ob diese Schwachstelle vor dem Patch bereits öffentlich gemacht wurde

    • Früher seien Beiträge, die erklärten, wie gut eine Schwachstelle ausnutzbar ist, meist erst Monate nach dem Patch erschienen; heute wünsche man sich, dass in jedem Beitrag klar und ausdrücklich zwischen „das ist gerade wirklich gefährlich“ und „das ist schon gepatcht, kein Grund zur Sorge“ unterschieden wird

• Beim Hinweis, man habe vom bestehenden Exploit nur „eine einfache Abwandlung“ gemacht, kommt die Frage auf, warum Git nicht Landlock verwendet (Landlock ist eine Linux-spezifische Sandbox-Sicherheitsfunktion)

  • Für git clone wird ein Modell vorgeschlagen mit nur lesendem Zugriff auf das Config-Verzeichnis, Lese-/Schreibrechten nur auf das Zielverzeichnis des Klons und einem Verbot von Unterprozess-Aufrufen

  • Dazu noch ein spöttischer Seitenhieb auf den typischen Exploit-Demo-Moment, bei dem immer ein Taschenrechner geöffnet wird

  • Es wird eingewandt, dass ein Verbot von Unterprozessen alle Git-Hooks wie post-checkout kaputt machen würde

    • Wenn man das nicht brauche, könne man Git auch in einer Container-Umgebung mit seccomp ausführen, aber viele Funktionen wären dann eingeschränkt

  • Außerdem wird darauf hingewiesen, dass Git über SSH ohne Unterprozesse ebenfalls nicht funktionieren würde

• Es wird gefragt, ob Homebrew selbst betroffen ist, also ob dort rekursives Klonen verwendet wird

  • In diesem Code wird eine mögliche Stelle gefunden

  • Es wird angemerkt, dass das Ziel von Homebrew ohnehin darin besteht, Code aus Repositories auszuführen, sodass es eher seltsam wäre, wenn kein rekursives Klonen verwendet würde

    • RCE sei nur dann wirklich relevant, wenn geklonte Daten eigentlich nicht ausgeführt werden sollten, und solche Fälle seien eher selten

• Beim Lesen eines bekannten Zitats von Jon Postel zu CR+LF werden nostalgische Erinnerungen wach

  • Es wird auf diesen Text verwiesen und die Einschätzung geteilt, dass dieser Rat im Vergleich zu 2003 heute womöglich nicht mehr passend ist
  • Wie Mark Crispin damals erläuterte, hätten viele Leute das missverstanden; außerdem wird das mit Fällen verbunden, in denen Daniel J. Bernstein Ende der 1990er auf Probleme bei Mensch-Maschine-Umwandlungen wie Parsing/Quoting hingewiesen hatte
  • Es wird beobachtet, dass auch nach 25 Jahren weiterhin Quoter-Code ohne Escape von CR geschrieben wird, und dass selbst nach dem Fix nicht sämtlicher Whitespace geprüft wird
  • Laut git blame wurde der problematische Code vor 19 Jahren geschrieben, was zeitlich mit Bernsteins Rückblick zum zehnjährigen Jubiläum zusammenfällt
  • Zusätzliche Materialien werden geteilt, darunter der betreffende Commit und das qmail-Paper
  • Am Ende wird betont, dass wir die mühsam im 20. Jahrhundert gewonnenen Lehren offenbar auch im 21. Jahrhundert immer wieder neu lernen müssen

• Für Homebrew ist das Update auf Git 2.50.1 offenbar noch nicht verfügbar, daher müsse man wohl noch etwas warten

  • Es wird auf diesen Issue verwiesen oder alternativ brew install git --HEAD empfohlen

• Es wird geteilt, dass sowohl Homebrew als auch Debian Bookworm weiterhin verwundbare Versionen ausliefern

  • Inzwischen sei Git 2.50.1 auch bei Homebrew verfügbar

• Es wird darüber nachgedacht, wie ein Systemaufruf zum Einlesen eines Verzeichnisinhalts reagieren sollte, wenn ein Dateiname ASCII-Steuerzeichen (Bytes) enthält: Sollte die Existenz der Datei geleugnet, dies als Festplattenkorruption behandelt oder anders damit umgegangen werden?

  • Da diese Bytes in der aktuellen Locale auch eine andere Bedeutung haben könnten und Dateinamen nicht wie unter Windows grundsätzlich als UTF-16 behandelt werden, könne es zu unerwarteten Situationen kommen

  • Es wird kurz darauf hingewiesen, dass Dateinamen (und andere Strings) auf Unix-artigen Systemen schlicht Bytefolgen sind, weshalb dieses Problem entsteht