Korrekturversionen des verteilten Verwaltungssystems fĂŒr Quelltexte Git 2.24.1, 2.23.1, 2.22.2, 2.21.1, 2.20.2, 2.19.3, 2.18.2, 2.17.3, 2.16.6, 2.15.4 und 2.14.62.24.1, in denen Schwachstellen behoben wurden, die es einem Angreifer ermöglichen, beliebige Pfade im Dateisystem zu ĂŒberschreiben, eine Remote-CodeausfĂŒhrung zu initiieren oder Dateien im Verzeichnis â.git/â zu ĂŒberschreiben. Die meisten Probleme wurden von Mitarbeitern des Microsoft Security Response Centers erkannt, fĂŒnf von acht Schwachstellen sind plattformspezifisch fĂŒr Windows.
Microsoft Security Response Center, fĂŒnf von acht Schwachstellen sind plattformspezifisch fĂŒr Windows.
- â Stream-Befehl «feature export-marks=path» schrieb Marken in beliebige Verzeichnisse, was genutzt werden kann, um beliebige Pfade im FS bei der AusfĂŒhrung des âgit fast-importâ-Befehls mit ungeprĂŒften Eingaben zu ĂŒberschreiben.
- â Fehlende Escape-Zeichen fĂŒr Kommandozeilenargumente zu einer Remote-CodeausfĂŒhrung des Angreifers bei rekursivem Klonen unter Verwendung von URL ssh://. Insbesondere wurde die Verarbeitung der Escape-Zeichen, die auf einen Backslash enden (z. B. âtest \â), nicht korrekt behandelt. In diesem Fall wurde das letzte AnfĂŒhrungszeichen beim Umgeben des Arguments mit doppelten AnfĂŒhrungszeichen escaped, was es ermöglichte, eigene Optionen in der Kommandozeile einzufĂŒgen.
- â beim rekursiven Klonen von Submodulen (âclone ârecurse-submodulesâ) unter Windows unter bestimmten Bedingungen die Verwendung eines git-Verzeichnisses zweimal initiieren (.git, git~1, git~2 und git~N wird in NTFS als dasselbe Verzeichnis erkannt, aber diese Situation wurde nur fĂŒr git~1 ĂŒberprĂŒft), was verwendet werden konnte, um Beschreibungen im Verzeichnis â.gitâ zu speichern. Um die AusfĂŒhrung eigenen Codes zu organisieren, könnte der Angreifer beispielsweise sein Skript ĂŒber den post-checkout-Handler in der Datei .git/config einfĂŒgen.
- â Der Handler fĂŒr die Buchstabennamen von Laufwerken in Windows-Pfaden bei der Ăbersetzung von Pfaden wie âC:\â war nur auf den Austausch von einbuchstabigen lateinischen Identifikatoren ausgelegt, berĂŒcksichtigt aber nicht die Möglichkeit, virtuelle Laufwerke zu erstellen, die ĂŒber âsubst Buchstabe:Pfadâ zugewiesen werden. Solche Pfade wurden nicht als absolute, sondern als relative Pfade behandelt, was es ermöglichte, beim Klonen eines bösartigen Repositories in beliebige Verzeichnisse auĂerhalb des Arbeitsverzeichnisses zu schreiben (z. B. bei der Verwendung von Zahlen oder Unicode-Zeichen im Laufwerksnamen â â1:\what\the\hex.txtâ oder âĂ€:\tschibĂ€t.schâ).
- â Bei der Arbeit auf der Windows-Plattform ermöglichte die Verwendung alternativer Datenströme in NTFS, die durch das HinzufĂŒgen des Merkmals â:stream-name:stream-typeâ zum Dateinamen erstellt wurden, das Ăberschreiben von Dateien im Verzeichnis â.git/â beim Klonen eines bösartigen Repositories. Zum Beispiel wurde der Name â.git::$INDEX_ALLOCATIONâ in NTFS als gĂŒltiger Verweis auf das Verzeichnis â.gitâ behandelt.
- â Bei der Verwendung von Git in einer WSL-Umgebung (Windows Subsystem for Linux) beim Zugriff auf das Arbeitsverzeichnis Schutz vor Manipulationen von Namen in NTFS angewendet (Angriffe ĂŒber die Ăbersetzung von FAT-Namen waren möglich, z.B. konnte auf â.gitâ ĂŒber das Verzeichnis âgit~1â zugegriffen werden).
- â
SchreibvorgĂ€nge in das Verzeichnis â.git/â auf der Windows-Plattform beim Klonen von bösartigen Repositories, die Dateien mit einem umgekehrten SchrĂ€gstrich im Namen (z.B. âa\bâ) enthalten, was in Unix/Linux zulĂ€ssig ist, jedoch als Teil des Pfads in Windows interpretiert wird. - â Unzureichende ĂberprĂŒfung von Submodulnamen konnte zur DurchfĂŒhrung gezielter Angriffe verwendet werden, die beim rekursiven Klonen potenziell zur AusfĂŒhrung von Angreifer-Code. Git erlaubte es nicht, ein Submodulverzeichnis im Verzeichnis eines anderen Submoduls zu erstellen, was in den meisten FĂ€llen nur zu Verwirrung fĂŒhren kann, jedoch potenziell das Ăberschreiben des Inhalts eines anderen Moduls wĂ€hrend des rekursiven Klonens ausschlieĂt (z.B. werden die Submodulverzeichnisse âhippoâ und âhippo/hooksâ als â.git/modules/hippo/â und â.git/modules/hippo/hooks/â abgelegt, und das Verzeichnis hooks in hippo kann separat zur Ablage von ausfĂŒhrbaren Handlern verwendet werden.
Windows-Nutzern wird dringend geraten, die Git-Version umgehend zu aktualisieren und bis zur Aktualisierung das Klonen von nicht verifizierten Repositories zu vermeiden. Sollte eine sofortige Aktualisierung der Git-Version nicht möglich sein, wird empfohlen, âgit clone ârecurse-submodulesâ und âgit submodule updateâ mit nicht verifizierten Repositories nicht auszufĂŒhren, âgit fast-importâ mit nicht verifizierten Eingabeströmen zu vermeiden und Repositories nicht in NTFS-basierten Partitionen zu klonen.
Zur zusĂ€tzlichen Sicherheit ist in neuen Versionen auch die Verwendung von Konstruktionen in der Form âsubmodule.{name}.update=!commandâ in .gitmodules untersagt. Um Updates fĂŒr Distributionen zu verfolgen, können die Seiten ,, , , , , , .
Quelle: opennet.ru
