Proof of Concept für CVE-2024-54756, eine Sicherheitslücke, die ich in GZDooms ZScript-Scripting-Engine gefunden habe.
Ein Proof of Concept für eine Schwachstelle in der ZScript-Funktionalität von GZDoom (https://github.com/zdoom/gzdoom), die ich entdeckt habe. Ein Angreifer kann eine PK3-Datei mit einer bösartigen ZScript-Quelldatei teilen und Zugriff auf den PC des Opfers erlangen.
Vielen Dank an Rachael und Agent Ash vom GZDoom-Entwicklerteam für ihre schnellen Antworten sowie an sie und die anderen GZDoom-Entwickler für die rasche Behebung dieses Problems!
Bestätigt funktionierend für 4.13.0 und 4.13.1, und dies funktioniert wahrscheinlich auch für frühere Versionen. Seien Sie vorsichtig bei Personen, die Ihnen raten, auf Version 4.13.1 oder niedriger zu downgraden, um ihr WAD spielen zu können.
Dieser PoC funktioniert nur unter Linux, aber die Schwachstelle existiert wahrscheinlich auch unter Windows. Nicht getestet unter ZDoom oder LZDoom, aber die Schwachstelle könnte dort ebenfalls vorhanden sein.
Die Schwachstelle wurde den Entwicklern vor der Veröffentlichung dieses PoC gemeldet und sollte in Version 4.13.2 nicht mehr vorhanden sein. Nach meinem besten Wissen enthält diese Version keine praktisch bedeutsamen Änderungen.
Dieser PoC wurde zu Bildungszwecken erstellt und veröffentlicht, damit Entwickler von Spiel-/Skript-Engines verstehen, wie Schwachstellen entstehen können, und Spieler verstehen, wie ein bösartiger Spielmod aussehen kann. Ich übernehme keine Verantwortung oder Haftung für den Missbrauch dieses PoC. Bitte verwenden Sie dies nicht, um die PCs Ihrer Mitspieler zu kompromittieren; es ist illegal (das sollte ich Ihnen nicht sagen müssen), und es ist besonders hinterhältig, den Computer eines anderen über ein Videospiel zu übernehmen.
Um diesen PoC zu verwenden, laden Sie dieses Repository herunter und erstellen Sie eine PK3-Datei (die eigentlich eine Zip-Datei mit der Erweiterung .pk3 ist), die zscript.zs und MAPINFO enthält:
git clone https://github.com/Chainmanner/GZDoom-Arbitrary-Code-Execution-via-ZScript-PoC
cd GZDoom-Arbitrary-Code-Execution-via-ZScript-PoC
zip PoC.pk3 zscript.zs MAPINFO
Das Standard-Payload besteht darin, eine Reverse-Shell zu localhost auf Port 1337 zu starten. Starten Sie den Listener:
nc -nvlp 1337
Führen Sie den PoC wie folgt aus:
gzdoom -iwad <your-doom-or-freedoom-wad> -file PoC.pk3
Wenn es funktioniert hat, sollten Sie jetzt eine Reverse-Shell zu sich selbst haben.
Dieser PoC ist nur für Linux. Möglicherweise funktioniert er nicht beim ersten Versuch; versuchen Sie es einfach erneut, bis es klappt.
HINWEIS: Dies ist mein erster Exploit-Bericht und ich arbeite noch an meinen Fähigkeiten für Low-Level-Berichte. Außerdem habe ich einen Großteil meines Debuggings mit GDB durchgeführt, und leider hatte ich nicht die gute Idee, einige Speicherabbilder zu speichern, um meine Erklärung besser zu veranschaulichen. Tut mir leid! Mein nächster Bericht wird besser, versprochen.
GZDoom ist ein Doom-Source-Port, der für Leistung und Erweiterbarkeit entwickelt wurde. Dank seiner leistungsstarken Funktionen wurden viele großartige WADs, Mods und sogar kommerzielle Total Conversions erstellt. Leider bietet Komplexität auch Raum für Schwachstellen, und in diesem Fall gab es zwei in der ZScript-Scripting-Engine, die eine vollständige Exploit-Kette ermöglichten.
Dieser Angriff umgeht ASLR und umgeht die Notwendigkeit, Stack-Canaries zu überwinden. Ich glaube nicht, dass Clangs CFI oder Shadow Stacks hier geholfen hätten.
Die erste und wichtigste Schwachstelle betraf die Behandlung großer Arrays. Wenn Sie ein ausreichend kleines Array allozieren, wird der allozierte Speicherbereich in der Regel mit Nullen gefüllt und ist ordnungsgemäß von anderen Objekten getrennt; durch Lesen von nicht initialisiertem Speicher können keine Informationen gewonnen werden, und keine Objekte überschneiden sich mit dem Array. Wenn Sie jedoch ein großes Array allozieren – sagen wir, 1073741823 32-Bit-Wörter oder mehr – können Sie bis zu 4 GiB potenziell nicht initialisierten Speichers vom Startpunkt des Arrays lesen und schreiben, was es dem Angreifer ermöglicht, andere Objekte direkt zu modifizieren und ASLR zu umgehen, indem er Adressen mit bekannten Offsets findet. Darüber hinaus werden alle weiteren Arrays, die nach diesem Punkt erstellt werden, mit dem großen Array überlappen.
Die zweite Schwachstelle lag in den Speicherzuordnungsberechtigungen. Aus Leistungsgründen wird ZScript-Code nach Möglichkeit per JIT in x86- oder x86-64-Bytecode kompiliert. Dazu muss der Code in einen Speicherbereich geschrieben werden, und dieser Speicherbereich muss ausführbar sein. Allerdings besagt die W^X-Regel, dass ein Bereich entweder beschreibbar oder ausführbar sein sollte, aber nicht beides. Wenn beides gleichzeitig angewendet wird (anstatt den Bereich beschreibbar zu machen, den Code zu schreiben und dann den Bereich ausführbar und nicht beschreibbar zu machen), kann ein Angreifer mit einem beliebigen Schreib-Primitiv dies zu einer beliebigen Codeausführung eskalieren; er kann Shellcode schreiben und zu ihm springen, z.B. durch Modifikation der Rücksprungadresse auf dem Stack (unter der Annahme, dass der Angreifer kein beliebiges Ausführungs-Primitiv hat). Wenn Sie sich die Speicherzuordnungen von GZDoom während des Laufs ansehen, sehen Sie mehrere RWX-Bereiche:
7fcd19700000-7fcd19800000 rwxp 00000000 00:00 0
7fcd1a100000-7fcd1a200000 rwxp 00000000 00:00 0
7fcd1eb00000-7fcd1ec00000 rwxp 00000000 00:00 0
Wenn also beliebige Schreib- und beliebige Ausführungs-Primitive verfügbar sind und der Angreifer weiß, wo sich ein RWX-Bereich befindet, kann er beliebigen Shellcode schreiben und ausführen. Diese Bereiche beim Schreiben des JIT-kompilierten Codes als RW- und dann beim Ausführen als R-X zu kennzeichnen, würde diesen PoC stoppen, aber es würde einen Angreifer nicht daran hindern, Codeausführung zu erlangen, z.B. durch Modifikation von Daten auf dem Stack (ROP) oder Heap.
Zusätzlich gibt es ein nützliches Gadget. Erinnern Sie sich daran, dass beim Allozieren eines großen Arrays alle weiteren Arrays, die danach erstellt werden, überlappen? Das schließt Arrays von Objektzeigern ein. Ähnlich wie C++-Objekte können ZScript-Objekte Variablen und Funktionszeiger enthalten. Angenommen, wir haben dieses Objekt:
class WeirdObject
{
uint one;
uint two;
uint three;
uint four;
Function<clearscope void()> funcptr;
}
Wenn wir ein Array erstellen, das einen Zeiger auf eine WeirdObject-Instanz enthält, dann kann der Angreifer den Zeiger mit dem großen Array an jede beliebige Stelle ändern und die gezeigten Daten durch Zugriff auf die Felder des Objekts ändern, was uns ein beliebiges Lese-/Schreib-Primitiv über den Heap hinaus ermöglicht. Zeiger in ZScript werden überprüft, um sicherzustellen, dass sie nicht null sind, aber nicht, um sicherzustellen, dass sie sinnvoll sind.
Das Vorhandensein eines Funktionszeigers gibt uns auch ein beliebiges Ausführungs-Primitiv; dies ist jedoch etwas weniger geradlinig und erfordert die Erstellung einer gefälschten VMFunction, um die virtuelle Maschine zufriedenzustellen. Sobald ein Aufruf einer ZScript-Funktion in den Exploit-Code eingeführt wird, wird dieser Code nicht mehr JIT-kompiliert. Funktioniert trotzdem, aber das Debuggen und Ausnutzen wird etwas umständlicher. Es könnte einen besseren Weg für diesen Teil geben, aber ich habe die GZDoom-Interna nicht gut genug studiert, um ihn zu kennen.
Eine Sache zu beachten: WeirdObject hat geerbte Membervariablen, daher beginnt das erste Member bei Offset 0x28.
Jetzt haben wir die folgenden Werkzeuge:
Wie verketten wir sie zu einem Exploit?