Zusammenfassung des Exploits (CVE-2022-24126)

Eine unzureichende Grenzüberprüfung eines Stack-Puffers und des Datenfeldgrößenfelds während der Verarbeitung von NRSessionSearchResult-Matchmaking-Daten erlaubt einem Angreifer die Ausführung beliebigen Codes. Der Stack-Overflow erlaubt es, die unteren zwei Bytes der vftable_ptr des DLMemoryInputStream-Objekts zu überschreiben, das intern vom Stream-Reader verwendet wird, und die Ausführung auf sorgfältig ausgewählten benachbarten Code umzuleiten. Eine clevere Ausnutzung der Struktur des DLMemoryInputStream-Objekts und des Datenfeldgrößenfelds ermöglicht dann eine beliebige Code-Umleitung, wobei RCX auf die Adresse unseres Pakets zeigt. Von dort aus kann eine Reihe von Code-Umleitungen über virtuelle Aufrufe mit unterschiedlichen Offsets (die nun auf die Adressen springen, die wir in den Paketpuffer geschrieben haben) verwendet werden, um die Ausführung beliebigen Codes zu erreichen.

Verteilungsvektoren (CVE-2022-24125)

Die Verteilungsvektoren machen diesen speziellen RCE besonders schwerwiegend (abgesehen davon, dass es sich bereits um einen RCE handelt). Der Exploit wird durch Matchmaking-Push-Anfragen mit NRSessionSearchResult-Informationen übertragen. Das bedeutet, dass der Angreifer jeden angreifen kann, der seiner Online-Sitzung beitritt. Insbesondere für DS3:

• Beschwörungen (PushRequestSummonSign)
• Eindringlinge der Dunklen Geister (PushRequestAllowBreakInTarget)
• Spieler, die über einen Bund beitreten (PushRequestVisit)
• Arenakämpfer (PushRequestAcceptQuickMatch)

Das ist bereits ziemlich schlimm, aber das wahre Potenzial wird durch die RequestSendMessageToPlayers-Anfrage freigesetzt:

message RequestSendMessageToPlayers { 
    repeated uint32 player_ids = 1; 
    required bytes push_message = 2;
}

Der Host verwendet diese Anfrage, um die Push-Nachricht PushRequestAllowBreakInTarget direkt an Eindringlinge zu senden, damit diese Spawn-Koordinaten erhalten und ihrer P2P-Sitzung beitreten können. Das ist alles. Das ist die einzige Art, wie diese Anfrage vom Spiel verwendet wird.

Dennoch erlaubt sie jedem Client, beliebige Push-Nachrichten an Hunderttausende bestimmter Spieler zu senden.

Ich kann nicht genug betonen, wie gefährlich das ist. Im Grunde kann jeder Spieler den Matchmaking-Server imitieren. Indem der Angreifer diese Anfrage verwendet, um den Exploit über eine PushRequestVisit zu versenden, kann jeder Online-Spieler gezielt angegriffen werden, solange seine Spieler-ID bekannt ist. Der Angreifer kann den Exploit auch sehr schnell an die gesamte Online-Spielerbasis senden, indem er mehrere Anfragen sendet, die jeweils einen großen Teil möglicher Spieler-IDs enthalten.

Die allgemeine Exploitationstaktik für alle Spiele

Während sich der RCE nicht genau auf jedes Spiel übertragen lässt, ist die Kernidee des Exploits, die dem Angreifer eine beliebige Code-Umleitung ermöglicht, dieselbe. Wenn dies erreicht werden kann, ist es sehr wahrscheinlich, dass eine spielspezifische virtuelle Aufrufkette oder ROP-Kette gefunden werden kann. Dieser „erste Schritt“ nutzt die folgenden Schwachstellen:

Fehler #1: Keine Grenzüberprüfung im Eintragslisten-Parser

Matchmaking-Push-Anfragen, die Sitzungsbeitrittsinformationen enthalten, speichern diese Informationen in einem benutzerdefinierten Binärformat, das aus einer Kette von längenbegrenzten Dateneinträgen besteht. Jeder Eintrag hat das folgende Format:

struct Entry
{
    uint32_t type_or_id; // nicht sicher, aber wahrscheinlich ein Typ (feste Länge = 2, variable Länge = 1 ?)
    uint32_t size;
    uint8_t data[size];
}

Die Spielfunktion, die für das Kopieren der Daten dieser Einträge verantwortlich ist, vertraut blind dem Größenfeld, was einen Out-of-Bounds-Lesezugriff verursacht. Dies kann von einem böswilligen Client ausgenutzt werden, indem das Größenfeld auf Werte wie 0x7FFFFFFF gesetzt wird, was zu einem Speicherzuweisungsfehler und einem Absturz des Spiels des Opfers führt. Später wird diese Größe auch an den Konstruktor eines DLMemoryInputStream übergeben, der ein wesentlicher Bestandteil des Exploits ist.

Fehler #2: Pufferüberlauf im NRSessionSearchResult-Parser

Einer der Einträge in der oben beschriebenen Datenstruktur ist ein serialisiertes NRSessionSearchResult-Objekt. Der Parser für diese Daten analysiert zuerst eine Liste von Eigenschaften. Diese Eigenschaften können 4-Byte-Ints, 8-Byte-Ints oder nullterminierte Breitstrings sein. Auf diese Eigenschaftenliste folgt der Steam-Persona-Name des Hosts als nullterminierter Breitstring sowie einige zusätzliche Daten, die für den Exploit nicht wichtig sind. Sowohl diese Funktion als auch der Eigenschaftenlisten-Parser verwenden einen Stack-Puffer fester Größe zum Lesen von Strings, und in beiden Fällen wird keine Grenzüberprüfung des Puffers durchgeführt. Hier ist der Spielcode, der für das Kopieren des Hostnamens verantwortlich ist (mit dem Ghidra-Decompiler erstellt und dann bereinigt):

size_t idx = 0;
wchar_t wchr = 0;
do {
  // read_wchar()-Funktion am vftable-Index 17 von DLEndianStreamReader
  wchr = stream_reader->read_wchar();
  player_name_buff[idx] = wchr;
  idx++;
} while (wchr != 0);

Dies führt zu einem Pufferüberlauf-Exploit, der es dem Angreifer ermöglicht, den Stack zu korrumpieren.

Vorbereitung der virtuellen Aufruf- / ROP-Kette

Um eine beliebige Code-Umleitung zu erreichen, nutzen wir dies und das Speicherlayout eines DLMemoryInputStream-Objekts, das vom aufrufenden Parser auf dem Stack instanziiert wird und intern vom Stream-Reader verwendet wird:

struct DLMemoryInputStream {
    uintptr_t* vftable_ptr; // Offset 0
    size_t data_size;       // Offset 4 (32bit) / 8 (64bit)
    uint8_t* data_buffer;   // Offset 8 (32bit) / 16 (64bit)
    // Einträge nach dem Puffer sind für den Exploit nicht wichtig
}

Da wir das data_size-Feld kontrollieren (Fehler #1), kann es auf die Stack-Speicheradresse des data_buffer-Felds gesetzt werden. Dies wird gelingen, vorausgesetzt die Adresse ist konstant und nicht zu groß (DS3 erfüllt diese Anforderungen). Da der Compiler den Stack-Puffer oben im Frame platziert, kann der Angreifer mit Fehler #2 die unteren zwei Bytes der vftable_ptr des DLMemoryInputStream überschreiben. Wenn das nächste Zeichen vom DLEndianStreamReader gelesen wird, ruft es intern den DLMemoryInputStream auf und der Code wird umgeleitet. Die 2 Bytes geben genug Spielraum, um zur 22. Funktion in der vftable des DLEndianStreamReader zu springen, die die 6. virtuelle Methode des Objekts aufruft, auf das sein erstes Feld zeigt. In einem 64-Bit-Prozess (d. h. Dark Souls III) würden die folgenden Anweisungen ausgeführt werden:

MOV       RCX,qword ptr [RCX + 0x8]
MOV       RAX,qword ptr [RCX]
JMP       qword ptr [RAX + 0x40]

Da RCX ein Zeiger auf das DLMemoryInputStream-Objekt ist, schreibt die erste Anweisung das data_size-Feld, das vom Angreifer mit Fehler #1 auf eine Stack-Adresse gesetzt wurde, die auf das data_buffer-Feld zeigt, in RCX. Die beiden nächsten Anweisungen leiten die Ausführung somit auf die Speicheradresse um, die der Angreifer bei Offset 0x40 im Datenpuffer geschrieben hat. Eine beliebige Code-Umleitung wurde nun erreicht! Von dort aus kann der Angreifer eine Kette von Code-Umleitungen aufbauen, die seine Payload in einen geeigneten Speicherbereich kopieren und ausführen, indem er Code in der Nähe von virtuellen Aufrufen mit verschiedenen Offsets auswählt, da der Puffer nun als virtuelle Methodentabelle fungiert. Für den Dark Souls III Proof of Concept habe ich ein Setup gefunden, das nur 3 Gadgets benötigt, um RCE zu erreichen:

• 0x18: 140e97700
• 0x40: 1422be020
• 0x68: 140e40f15

Dark Souls III Proof-of-Concept-Code

Ausführen des PoC-Codes

Angriffsvektor

Für den Proof of Concept habe ich mich für eine PushRequestVisit-Nachricht entschieden, die mit RequestSendMessageToPlayers gesendet wird. Dies ist die wirksamste Version des Exploits in dem Sinne, dass das Spiel des Ziels die verwundbaren Daten sofort nach Erhalt in allen Situationen (auch im Hauptmenü) verarbeitet.

Virtuelle Aufruf-Umleitungskette

Offset 0x18: 140e97700

LEA       RAX,[DAT_144786150]
RET

Dieses Gadget wird in dem bei 0x68 verwendet. Wir müssen eine Adresse, die niedriger, aber ziemlich nahe an 144786998 liegt, in RAX laden; dies ist die nächstgelegene.

Offset 0x40: 1422be020

MOV       RDX,RAX
MOV       R8,qword ptr [RCX]
CALL      qword ptr [R8 + 0x68]

Um das Gadget bei Offset 0x68 verwenden zu können, muss die Datenpufferadresse in RDX gespeichert sein und RCX unverändert bleiben. Dies wird hiermit genau erreicht.

Offset 0x68: 140e40f15

; Sprung hierher vom Gadget bei Offset 0x40
MOV       RBX,RDX
CMP       R9,R8

 ; Springt nie, R9 != R8
JZ        LAB_140e40f7a
MOV       RAX,qword ptr [RCX]
MOV       R8,qword ptr [RSP + 0x50]
MOV       RDX,R9
MOV       qword ptr [RSP + 0x30],RSI

; Aufruf-Gadget bei Offset 18 (140e97700). Lädt 144786150 in RAX
CALL      qword ptr [RAX + 0x18]
MOV       RSI,RAX
TEST      RAX,RAX

; Springt nie, RAX ist die Datenpufferadresse.
JZ        LAB_140e40f4d 
CMP       RBP,RDI
MOV       RDX,RBX
MOV       RCX,RAX
CMOVC     RDI,RBP
MOV       R8,RDI ; RDI ist eine Stack-Adresse nahe 14F3B0, daher ist der memcpy erfolgreich
CALL      memcpy

LAB_140e40f4d:
TEST      RBX,RBX
; Springt nie, da RBX == RDX == Datenpufferadresse, ungleich null.
JZ        LAB_140e40f62 

; Wir haben nun die vollständige Kontrolle über diesen RWE-Speicherbereich aufgrund des memcpy bei 144786150. RCE wurde erreicht!
MOV       RCX,qword ptr [DAT_144786998]
MOV       RDX,RBX
MOV       RAX,qword ptr [RCX]
CALL      qword ptr [RAX + 0x68]

Dieses Gadget erledigt fast alles für uns. Es ruft Offset 0x18 auf, um einen memcpy-Zielzeiger zu erhalten, kopiert unser Paket dorthin und ruft dann die virtuelle Funktion bei Offset 0x68 auf dem statischen Objekt bei 144786998 auf, das wir nun aufgrund des memcpy-Aufrufs vollständig kontrollieren. Da die durch den memcpy beschädigte Speichermenge groß ist und einige Regionen ständig von anderen Spiel-Threads beschrieben werden, lädt der Exploit zuerst eine „Setup“-Payload, die an einen sicheren Ort kopiert wird, unterbricht alle anderen Threads und kopiert unsere tatsächliche Payload erneut, bevor er zu ihr springt. Weitere Informationen finden Sie in rce.h.

Zusätzliche Informationen

Ich empfehle, sich den Quellcode des Proof-of-Concept-Codes anzusehen, da er viele Kommentare zur Struktur des Pakets enthält. Wenn Sie sehen möchten, was bei jedem Schritt in Echtzeit passiert (das sollten Sie, es ist ziemlich cool!), können Sie die Proof-of-Concept-DLL injizieren, während das Spiel unter einem Debugger mit Haltepunkten an den folgenden relevanten Adressen läuft:

140ca5960

Im Wesentlichen, wo der Exploit beginnt. Diese Funktion ist für das Parsen der größenbegrenzten Eintragslistendaten der PushRequestVisit-Nachricht verantwortlich. Sie extrahiert zuerst jeden Eintrag der Liste in verschiedene Vektoren:

0x140ca59f8:
    player_data_cpy_ptr = (std_vector *)VectorCopy2_140ca4ef0(&player_data_cpy,player_data);
    FUN_140ca5010(player_data_cpy_ptr,&spawn_data,0x1c);
    FUN_140ca5010(player_data_cpy_ptr,&unk,4);
    FUN_140ca4fa0(player_data_cpy_ptr,&nrssr_data);