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.

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 e il codice verrà reindirizzato. I 2 byte danno abbastanza margine per saltare alla 22ª funzione nella vftable di , 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:

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

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