WorstFit: Versteckte Konverter in Windows ANSI aufgedeckt
TL;DR
- Wir haben eine neue Angriffsfläche entdeckt, indem wir die interne Zeichenkonvertierungsfunktion von Windows, Best-Fit, ausgenutzt haben.
- Diese Funktionalität wird in reale Angriffe wie Pfad-Traversal, Argument-Injection und Remote Code Execution (RCE) umgewandelt.
- Die Ursachen liegen bei Compiler-Verhalten, der C/C++-Runtime und Fehlern seitens der Entwickler.
- Es wird auch die Schwierigkeit diskutiert, Patches im Open-Source-Ökosystem einzuführen.
Windows-Kodierung im Überblick
Früher: ANSI und Codepages
- Windows verwendete zunächst ANSI-Kodierung, die für bestimmte Sprachen effektiv war, aber keine gemischten Zeichensätze verarbeiten konnte.
- Es gibt verschiedene Codepages, wobei jede Codepage eine bestimmte Sprache unterstützt.
Unicode-Ära: UTF-16
- Windows wechselte Mitte der 1990er Jahre zu Unicode, sodass fast alle Zeichen nahezu aller Sprachen in einem einzigen Standard dargestellt werden konnten.
- Zunächst wurde UCS-2 verwendet, kurz darauf auf UTF-16 aktualisiert.
Ära der doppelten Kodierung
- Windows implementierte zwei API-Versionen, um alte ANSI-Codepages weiterhin zu unterstützen.
- Mit der ANSI API und der Unicode API kann ein Entwickler je nach Bedarf einfach das gewünschte Datenformat erhalten.
Vorteile von Best-Fit
- Die Best-Fit-Zeichenkonvertierung von Windows beschreibt, wie beim Konvertieren von UTF-16 nach ANSI Zeichen verarbeitet werden, die in der Ziel-Codepage nicht vorhanden sind.
- Zum Beispiel ist das Symbol
∞ in der Windows-1252-Codepage nicht vorhanden, daher mappt Microsoft es auf 8.
WorstFit: neue Angriffsfläche in Windows
🔥 Der Ostasien-Albtraum - CVE-2024-4577
- CVE-2024-4577 ist eine Schwachstelle, mit der ein PHP-CGI-Server mit chinesischer oder japanischer Codepage mit einer einfachen Anfrage
?%ADs kompromittiert werden kann.
- Durch das Best-Fit-Verhalten wird U+00AD (Soft-Hyphen) auf einen Bindestrich (-) gemappt, was eine Umgehung ermöglicht.
🔥 Dateinamen-Spoofing
- Durch den Missbrauch von WorstFit bei der Dateinamenverarbeitung kann es in eine Path-Traversal-Nutzlast umgewandelt werden.
- Beispielsweise ruft die Chrome V8 Developer Shell (
d8.exe) über die ANSI API das aktuelle Arbeitsverzeichnis ab.
🔥 Argument-Splitting
- Durch Manipulation der Ausgabe von
GetCommandLineA kann das Worst-Fit-Verhalten bei der Befehlszeilenanalyse ausgenutzt werden.
- Zum Beispiel kann die Eingabe
＂ --use-askpass=calc ＂ dazu führen, dass das System calc.exe ausführt.
Fazit
- Das Best-Fit-Verhalten schafft eine Angriffsfläche während systemweiter Konvertierungsvorgänge und kann in verschiedenen Werkzeugen zu Schwachstellen führen.
- Solche Angriffe lassen sich mit Funktionen aus Standardbibliotheken oder Programmiersprachen nicht vollständig verhindern.
1 Kommentare
Hacker News Kommentare
Microsoft ist diesem Problem bereits seit mindestens einem Jahr bewusst. Über die spezielle Code-Analyse-Regel CA2101 wird empfohlen, die Verwendung von Best-Fit-Mapping zu vermeiden. Eine Sicherheitslücke wurde zwar erwähnt, aber die Details blieben vage.
Das Problem ist systemisch. Microsoft stellt ein „best fit“-Code-Mapping von Unicode zu ASCII bereit. Diese Zuordnung wird an vielen Stellen verwendet und muss wegen der hohen Priorität auf Abwärtskompatibilität offenbar weiter enthalten bleiben. Im Grunde ist sie über alles verteilt.
Sie wird vor allem ausgenutzt, indem ungültige Codepoints in Zeichen wie Schrägstriche, Bindestriche oder Anführungszeichen umgewandelt werden. In modernen Programmiersprachen wird das korrekt ausgewertet, aber Probleme treten auf, wenn es an Shell-Befehle oder die Win32-API übergeben wird.
Der curl-Maintainer sagt, dass curl das Opfer sei, doch die eigentliche Ursache liegt an anderer Stelle. Wenn die Benutzereingabe bei der Servervalidierung anders verarbeitet wird als bei der Anwendung in Systembibliotheken, entsteht das Problem.
Im Win32-Bereich könnte es eine Lösung sein, die „best fit“-Konvertierung selektiv zu deaktivieren. Open-Source-Anbieter können das als Best Practice übernehmen.
Windows kann, ähnlich wie das Munchkin-Kartenspiel, mehrere Features kombinieren und dadurch eine starke Schwachstelle erzeugen. Die Konvertierung des ANSI-Subsystems auf UTF-8 könnte das Problem abschwächen.
Microsoft hat ANSI seit NT 3.5 schrittweise aus der Verwendung genommen und die Nutzung der Wide-Character-API gefördert. Der wichtigste Stolperstein ist jedoch die Implementierung der C/C++-Runtime-Bibliothek von Microsoft.
Es ist unwahrscheinlich, dass Microsoft UTF-8 standardmäßig in allen Windows-Versionen aktiviert. Denn alte Anwendungen hängen oft von bestimmten Codepages oder einem Ein-Byte-Zeichensatz ab.
In einer Anwendung gibt es zwei Möglichkeiten, die „Ansi“-Codepage auf UTF-8 zu erzwingen: entweder über die Manifest-Datei oder über das Tool „App Locale“.
Auf meinem privaten Windows-PC habe ich den UTF-8-Modus auf Aktiv gesetzt und war dadurch vor diesem Bug sicher. Ich habe es aktiviert, weil alte ausländische Spiele kaputten Text angezeigt haben.
Das Problem ist nicht einfach gelöst, indem man nur
main()durch die Wide-Character-Version ersetzt. Man müsste alle Variablen aufwchar_t *umstellen, was schmerzhaft und fehleranfällig ist.charnutzt. Man muss nur darauf achten, keine ANSI- oder OEMCP-Zeichenketten mit UTF-8-Zeichenketten zu mischen.Mir war bekannt, dass Windows API Best-Fit-Konvertierung anbietet, aber dass dies der Standard ist, nicht.
Ich habe mich gefragt, ob die Beta-Checkbox dem Setzen von
ActiveCodePageauf UTF-8 entspricht. Die GDI folgt der prozessspezifischen Codepage nicht und nur der globalen Codepage. Schade, dass man nicht vollständig auf UTF-8 wechseln kann