Resumen del exploit (CVE-2022-24126)

La comprobación inadecuada de límites en un búfer de pila y en el campo de tamaño de datos durante el análisis de los datos de emparejamiento de NRSessionSearchResult permite a un atacante ejecutar código arbitrario. El desbordamiento de pila permite sobrescribir los dos bytes inferiores de vftable_ptr del objeto DLMemoryInputStream utilizado internamente por el lector de flujo, redirigiendo la ejecución a código vecino cuidadosamente elegido. La explotación inteligente de la estructura del objeto DLMemoryInputStream y de su campo de tamaño de datos permite entonces lograr la redirección de código arbitrario, con RCX apuntando a la dirección de nuestro paquete. A partir de ahí, se puede usar una serie de redirecciones de código mediante llamadas virtuales con diferentes desplazamientos (que ahora saltarán a las direcciones que escribimos en el búfer del paquete) para lograr la ejecución de código arbitrario.

Vectores de distribución (CVE-2022-24125)

Los vectores de distribución son lo que hace que este RCE en particular sea especialmente grave (más allá de ser ya un RCE). El exploit se transmite a través de solicitudes push de emparejamiento que contienen información de NRSessionSearchResult. Esto significa que el atacante puede apuntar a cualquiera que se una a su sesión en línea. En particular, para DS3:

• invocaciones (PushRequestSummonSign)
• invasores de espíritu oscuro (PushRequestAllowBreakInTarget)
• jugadores que se unen mediante pacto (PushRequestVisit)
• combatientes de arena (PushRequestAcceptQuickMatch)

Esto ya es bastante malo, pero el verdadero potencial se desbloquea con la solicitud RequestSendMessageToPlayers:

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

El anfitrión usa esta solicitud para enviar directamente el mensaje push PushRequestAllowBreakInTarget a los invasores, de modo que puedan obtener las coordenadas de aparición y unirse a su sesión P2P. Eso es todo. Esa es la única forma en que el juego usa esta solicitud.

La táctica general de explotación para todos los juegos

Si bien el RCE no se traslada exactamente a todos los juegos, la idea central del exploit, que le da al atacante redirección de código arbitrario, es la misma. Si esto se puede lograr, es muy probable que se pueda encontrar una cadena de llamadas virtuales o una cadena ROP específica del juego. Este "primer paso" utiliza las siguientes vulnerabilidades:

Bug #1: Sin comprobación de límites en el analizador de listas de entradas

Las solicitudes push de emparejamiento que contienen información de unión a sesión almacenan dicha información en un formato binario personalizado que consiste en una cadena de entradas de datos delimitadas por longitud. Cada entrada tiene el siguiente formato:

struct Entry
{
    uint32_t type_or_id; // not sure, but probably a type (fixed length = 2, variable length = 1 ?)
    uint32_t size;
    uint8_t data[size];
}

La función del juego responsable de copiar los datos de estas entradas confía ciegamente en el campo de tamaño, lo que crea una lectura fuera de límites. Un cliente malintencionado puede abusar de esto estableciendo el campo de tamaño a valores como 0x7FFFFFFF, lo que hace que la asignación de memoria falle y el juego de la víctima se bloquee. Más tarde, este tamaño también se pasa al constructor de un DLMemoryInputSteam, que es una parte instrumental del exploit.

Bug #2: Desbordamiento de búfer en el analizador de NRSessionSearchResult

Una de las entradas en la estructura de datos descrita anteriormente es un objeto NRSessionSearchResult serializado. El analizador de estos datos primero analiza una lista de propiedades. Estas propiedades pueden ser enteros de 4 bytes, enteros de 8 bytes o cadenas anchas terminadas en nulo. A esta lista de propiedades le sigue el nombre de persona de Steam del anfitrión como una cadena ancha terminada en nulo y algunos datos adicionales que no son importantes para el exploit. Tanto esta función como el analizador de la lista de propiedades usan un búfer de pila de tamaño fijo para leer cadenas, y en ambos casos no se realiza ninguna comprobación de límites en el búfer. Aquí está el código del juego responsable de copiar el nombre del anfitrión (producido con el descompilador de Ghidra y luego limpiado):

size_t idx = 0;
wchar_t wchr = 0;
do {
  // read_wchar() function at vftable index 17 of DLEndianStreamReader
  wchr = stream_reader->read_wchar();
  player_name_buff[idx] = wchr;
  idx++;
} while (wchr != 0);

Esto conduce a un exploit de desbordamiento de búfer, que permite al atacante corromper la pila.

Preparando el terreno para la cadena de llamadas virtuales / ROP

Para lograr la redirección de código arbitrario, usamos esto y el diseño de memoria de un objeto DLMemoryInputStream instanciado en la pila por la función que llama al analizador, y que es utilizado internamente por el lector de flujo:

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)
    // Entries after the buffer are not important for the exploit
}

Dado que controlamos el campo data_size (Bug #1), se puede establecer en la dirección de memoria de pila del campo data_buffer. Esto tendrá éxito siempre que la dirección sea constante y no demasiado grande (DS3 cumple esos requisitos). Dado que el compilador coloca el búfer de pila en la parte superior del marco, el atacante puede usar Bug #2 para sobrescribir los dos bytes inferiores de vftable_ptr del DLMemoryInputStream. Por lo tanto, cuando el DLEndianStreamReader lea el siguiente carácter, llamará internamente al y el código será redirigido. Los 2 bytes dan suficiente margen para saltar a la función número 22 en la vftable de , que llama al sexto método virtual del objeto apuntado por su primer campo. En un proceso de 64 bits (es decir, Dark Souls III), se ejecutarían las siguientes instrucciones:

Código de prueba de concepto para Dark Souls III

Ejecutar el código PoC

Vector de ataque

Para la prueba de concepto decidí usar un mensaje PushRequestVisit enviado mediante RequestSendMessageToPlayers. Esta es la versión más potente del exploit, en el sentido de que el juego del objetivo analizará inmediatamente los datos vulnerables después de recibirlos en todas las situaciones (incluso en el menú principal).

Cadena de redirección de llamadas virtuales

Offset 0x18: 140e97700

LEA       RAX,[DAT_144786150]
RET

Este gadget se usa en el de 0x68. Necesitamos poner en RAX una dirección inferior pero bastante cercana a 144786998; esta es la más cercana.

Offset 0x40: 1422be020

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

Para poder usar el gadget en el offset 0x68, necesitamos que la dirección del búfer de datos esté almacenada en RDX y que RCX permanezca igual. Esto logra precisamente eso.

Offset 0x68: 140e40f15

Información adicional

Recomiendo revisar el código fuente del código de prueba de concepto, ya que tiene muchos comentarios que detallan la estructura del paquete. Si quieres ver lo que sucede en cada paso en tiempo real (¡deberías, es bastante genial!), puedes inyectar la DLL de la prueba de concepto mientras ejecutas el juego bajo un depurador con puntos de interrupción en las siguientes direcciones de interés:

140ca5960

Esencialmente donde comienza el exploit. Esta función es responsable de analizar los datos de la lista de entradas delimitadas por tamaño del mensaje PushRequestVisit. Primero extrae cada entrada de la lista en diferentes vectores:

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