デモ

cve-2024-38063.webm

大まかなRCA

技術的な詳細に興味がある場合は、Marcus によるこの優れた脆弱性の分析を読むことをお勧めします。以下に書いた内容は、本格的な技術分析というよりは要約を目的としています。

• 特定の状況では、Windowsは複数のIPパケットを結合（コアレス）して一括処理します。まず各パケットの拡張ヘッダーを処理し、その後に各パケットのデータの処理に移ります。
• 拡張ヘッダーの処理中、結合されたこれらのパケットのパケットオブジェクトはリンクリストで連結されます。各パケットオブジェクトには、バッファリングされたパケットデータを含む NET_BUFFER オブジェクトが含まれています。オフセット 0x30 には、パケットがどこまで解析されたかを示す現在オフセットフィールドもあります。この段階では、オフセット値は通常 0x28 であり、IPv6ヘッダーが解析されただけで他はまだ解析されていないことを示します。
• tcpip!Ipv6pReceiveDestinationOptions で「宛先オプション」拡張ヘッダーを処理する際、解析エラーが発生すると tcpip!IppSendErrorList が呼び出されます。この関数は、リンクリスト内の各パケットオブジェクトに対して（現在のオブジェクトから順に）tcpip!IppSendError を呼び出します。
• 特定の条件下（例: パケットがユニキャストの場合）では、tcpip!IppSendError に副作用があります。バッファリングされたパケットデータを先頭に「巻き戻し」、現在オフセットフィールドをゼロにリセットします。
• しかし、この一連の処理の中で、エラーとしてマークされるのは最初のパケットのみです（オフセット 0x8C）。つまり、ドライバは IppSendError で「巻き戻された」パケットであっても、リンクリスト内の他のパケットの拡張ヘッダーの解析を続行します。
• 巻き戻されたパケットの処理は、想定外のデータに対して行われます。バッファリングされたパケットデータは拡張ヘッダーではなくパケットの先頭（つまりIPv6ヘッダー）を指しており、オフセットフィールドの値も 0x28 ではなくゼロになっています。

戦略

• この脆弱性を悪用するために、Ipv6pReceiveFragment を使用します。この関数はフラグメント拡張ヘッダーを解析し、現在のオフセット値から 0x30 を減算してパケット内の非ヘッダーデータの長さを計算する際、パケットのオフセットフィールドが少なくとも 0x28 であると想定します。この値は、フラグメント化されたパケットを再構築するための再構築オブジェクトに格納されます。
• 今回の場合、この関数は IppSendError によって巻き戻されたパケットに対して呼び出されます。オフセット値はゼロで、Ipv6pReceiveFragment の前半で 8 に増加します。非ヘッダーデータのサイズを計算すると、値はアンダーフローして 0xffd8 になります（減算は16ビットで行われます）。
• この長さの値が後で使用されるのは、次の2箇所のみです:
  • Ipv6pReassembleDatagram - 再構築されたパケットの出力バッファの長さを計算するために使用されます。ただし、すべての計算は32ビットで行われ、合計長が 0xFFFF を超えないかどうかの健全性チェックがあります（この場合は実際に超えます）。
  • Ipv6pReassemblyTimeout - ここでも同じ方法で使用されます。ただし、ここでの計算は16ビットで行われ、整数オーバーフローが発生します。これにより、後でバッファにデータをコピーする際にバッファオーバーフローが発生します。

Ipv6pReassemblyTimeout をトリガーするには、フラグメントの送信者が1分間非アクティブである必要があります。私たちの戦略は次のとおりです:

• 不正な宛先オプションを送信して IppSendError をトリガーし、その後にフラグメントパケットを送信する
• 2つのパケットが結合され、2番目のパケットのオブジェクトのデータとオフセットがリセットされることを期待する
• Ipv6pReceiveFragment でアンダーフローを発生させ、16ビットの大きな値を持つフラグメントデータ長の新しい再構築オブジェクトを作成する
• それ以上パケットを送信せずに1分間待ち、Ipv6pReassemblyTimeout がトリガーされるようにする
• Ipv6pReassemblyTimeout のバッファサイズ計算で整数オーバーフローを発生させ、ヒープベースのバッファオーバーフローをトリガーする

スクリプト内のパケットは、結合される可能性を高めるために大量に送信されます。メインのペイロードは非常にシンプルです:

• 解析エラーを引き起こす不正なオプションデータを含む「宛先オプション」拡張ヘッダーを持つIPv6パケット
• 最初のパケットに連結されることを期待するIPv6フラグメント #1
• IPv6フラグメント #2（同じID）。最初の2つにも連結される可能性がありますが、その主な目的は2番目のフラグメントを完成させ、通常の処理が行われた場合にエラーが破棄されないようにすることです。

また、IPv6ヘッダーのホップリミットフィールドとフローラベルフィールドも手動で設定します。脆弱性によりバッファリングされたパケットデータがリセットされることを思い出してください。つまり、フラグメントパケットを処理する際、IPv6ヘッダーがフラグメントヘッダーデータとして解釈されることになります。IPv6ヘッダーのホップリミットフィールドは、フラグメントヘッダーのIDフィールドのビットの1つとして解釈されます。これを変更することで、複数の異なるフラグメントに対して脆弱性をトリガーし、複数の異なる破壊を引き起こしてクラッシュの可能性を高めます（結局これはPoCなので）。IPヘッダーのフローリミットフィールドは、フラグメントヘッダーのオフセットおよび「継続フラグ」フィールドとして解釈されます。これを 1 に設定することで、後続のヘッダーがまだあること（そのため後で Ipv6pReassemblyTimeout をトリガーできる）と、オフセットがゼロであること（このIDの最初のパケットが到着するため）を示します。

備考

• 上記は、脆弱性をトリガーして引き起こされる問題を悪用するための1つの戦略に過ぎません。この戦略は非常に簡単だったので、他の可能性を調べる時間を無駄にしたくありませんでした。すぐに他の人々がもっと良い戦略を発表しても驚きません。
• この脆弱性に必要なもの:
  • ターゲットシステムのIPv6対応、パケットを受信できること（ファイアウォール処理前）
  • 送信したパケットをターゲットシステムにある程度結合（コアレス）させられること。アダプタとドライバの組み合わせによっては非常に積極的にこれを行うものもありますが、慎重なものもあるようです。アダプタやネットワークの状態に関係なく、Windows RSC にパケットを結合させるために使用できるトリックや特別なパケットチェーンが存在する可能性はありますが、その証拠はありません。
• この脆弱性に不要なもの:
  • パケットの大量送信。PoCがこれを行うのは、結合の可能性を高め、デモンストレーションとして複数の破壊をトリガーするためだけです。
  • ターゲットシステムの高負荷状態。結合はさまざまな状況で発生し得るためです。
  • IPv6が有効であること以外の、ターゲットシステム上の特定の設定。
  • （おそらく）破壊をトリガーするための1分間の待機。これは最も簡単だったため、この悪用戦略を使用しただけです。脆弱性によって引き起こされる問題のある状態が、より直接的な方法で悪用される可能性は十分にあります。
  • （おそらく）ユニキャストパケット。Ipv6pReassemblyTimeout で使用しているコードパスが、元のフラグメントパケットをユニキャストで送信することを必要とするため、これを使用しています。

トラブルシューティング

うまくいかない場合、原因として考えられるもの:

• ターゲットシステムにIPv6経由で到達できない:
  • Windowsファイアウォールを無効にする
  • ホストPCから ping -6 {ipv6_address} を実行する
  • 応答が返ってくることを確認する
  • ファイアウォールを再度有効にする
• ターゲットシステムがパケットを受信していない:
  • ターゲットシステムにWiresharkをインストールし、スクリプトが送信したパケットが届いているか確認する
• scapyが "Mac address to reach destination not found. Using broadcast." と報告している:
  • ターゲットマシンのMACアドレスを見つける必要があります
  • これは、上記のpingコマンドを実行し、Wiresharkで応答（eth送信元アドレスフィールド）を確認することで見つけることができます
  • また、scapyを使用することもできます: Ether(raw(sr1(IPv6(dst={your_dest_ip})/ICMPv6EchoRequest()))).src。ただし、これはうまくいかないこともあります
  • MACアドレスが分かったら、スクリプトの mac_addr フィールドに入れてスクリプトを実行します
• ターゲットシステムでパケットが結合されない:
  • お使いのネットワークアダプタ/ドライバによっては、DDOSのようなターゲットへのフラッディングに頼らずにWindowsにパケットを結合させるのは難しい場合があります。
  • 利用可能な設定に応じて、アダプタ設定を変更してみることもできます。例: "Packet Coalescing"、"Interrupt Moderation"、"Interrupt Moderation Mode"、"Recv Segment Coalescing"。例えば、私の専用サーバーでは "Interrupt Moderation Mode" を "Extreme" に設定すると、この脆弱性を再現できるようになります。
• それでもダメな場合は、カーネルデバッガをアタッチしていくつか確認できます:
  • tcpip!Ipv6pReceiveDestinationOptions -> tcpip!Ipv6pProcessOptions -> tcpip!IppSendErrorList がヒットしているか？
  • tcpip!Ipv6pProcessOptions にブレークポイントを設定し、[rcx] が常にゼロかどうか確認する。ゼロの場合、何らかの理由でパケットが結合されていません。
  • tcpip!Ipv6pReceiveFragment にブレークポイントを設定し、[rcx+0x30] がゼロに等しいか確認する。ゼロでない場合、何らかの理由で脆弱性のトリガーに失敗しています。