RPC ランタイムにおける 3 つのリモートコード実行脆弱性を探る

MS-RPC は Windows ネットワークで頻繁に使用されるプロトコルであり、多くのサービスやアプリケーションがこのプロトコルに依存しています。そのため、MS-RPC の脆弱性は甚大な影響を及ぼす可能性があります。Akamai Security Intelligence Group はこの 1 年間、MS-RPC の調査に取り組んできました。私たちは脆弱性を見つけて悪用し、調査ツールを構築して、このプロトコル内の文書化されていない部分を文書にまとめました。 

これまで投稿したブログでは、サービスの脆弱性に焦点を当てていましたが、今回は MS-RPC の"エンジン"である RPC ランタイムの脆弱性を検証します。これらの脆弱性は、 2022 年 5 月に発見された脆弱性と類似しています。

脆弱性をトリガーするためには、その根本原因を理解し、脆弱な関数へのフローが存在するかどうかや、トリガーにかかる時間を把握する必要があります。

簡潔にするために、3 つの脆弱性の 1 つである Queue（キュー）データ構造の脆弱性について説明します。他の 2 つの整数オーバーフローも性質が似ているので、以下のセクションの分析はこれらにも当てはまります。

前述のとおり、この脆弱性は新しいエントリの挿入で発生します。動的配列が満杯状態の場合、コードは次の処理を実行します。

• 次のサイズの新しい配列を割り当てます。
  CurrentCapacity*2*sizeof（QueueEntry）

• 古いアイテムを新しい配列にコピーします

• 古いアイテムの配列を解放します

• 容量を 2 倍にします

32 ビットシステムの場合、新しい配列サイズの計算でオーバーフローが発生します。

• キューに 0x10000000（!）のアイテムを入力します。 

• 拡張が生じます。新しい割り当てサイズが計算され、0x10000000 * 16 になります。  オーバーフローとなり、新しい割り当てサイズは 0 になります。 

• 長さゼロの配列が割り当てられます。

• コードにより、古いアイテムの配列が新しい小さな配列にコピーされます。これにより、ワイルドコピー（大きなリニアコピー）が作成されます。

64 ビットシステムでは、大きな割り当てがあると、失敗になるので、この脆弱性を悪用することはできません。コードは境界外の書き込みをトリガーせず、正常に終了します。64 ビットシステムは、この問題に対しては脆弱ではありませんが、 他の整数オーバーフローに対しては脆弱です （SIMPLE_DICT と SIMPLE_DICT2）。

RPC 接続は、OSF_SCONNECTION クラスを使用して表現されます。各接続で複数のクライアントコール（OSF_SCALL）を処理できますが、その接続において 指定時間に実行が許可されるコールは 1 つだけ であり、他のコールはキューに入れられます。 

そのために、キューを使用する興味深い関数、OSF_SCONNECTION::MaybeQueueThisCall が使用されています。 この関数は、接続に到達した新しいコールのディスパッチの一部として呼び出されます。この場合、キューは別のコールが処理されている間、着信したコールを"保留する"ために使用されます。

したがって、キューへの挿入はユーザーが制御できますが（クライアントコールを順番に送信することによって）、この関数は要件として、その接続で現在、コールが処理中であることを必要とします。つまり、キューに入れるには、完了に時間がかかるコールが必要になるのです。コールが処理されている間に、ディスパッチキューを埋める新しいコールを複数個送信します。 

では、完了に最も時間のかかるのはどのような関数コールでしょうか。 

• 最適な候補は、無限ループを発生させることができる関数です。

• 次に最適なオプションは認証強制の脆弱性です。サーバーが私たちに接続するので、応答時間を制御できます。

• 最後の手段は、複雑な論理を持つ複雑な関数や、大量のデータを処理するため完了に時間がかかる関数です。

私たちは、 独自の認証強制の脆弱性を使用することにしました。

キューへの挿入に必要なものや、使用可能な方法はわかりましたが、ここで 1 つ重要な疑問が浮上します。それは現実に実行可能なのかという問題です。

私たちには、整数オーバーフローを発生させる変数に対する最低限の制御力しかありません。refcount（参照カウント）と同様に一度に 1 つしかインクリメントできないのです。この種の整数オーバーフローは、完全に制御できる 2 つの変数の加算や乗算によるものや、追加サイズをある程度制御できる場合（パケットサイズなど）よりも少し扱いにくくなります。

先ほど述べたとおり、0x10000000（~268M）のアイテムを割り当てる必要があります。これは大変です。

私のマシンでこの脆弱性をトリガーしてみると、キューに入れられるコールは 1 秒あたり約 15～20 個程度でした。 つまり、平均的なマシンでトリガーする場合、約 155 日かかることになります。 私たちは、キューに挿入される 1 秒あたりのコール数はもっと多いと想定していました。RPC ランタイムがこんなに遅いのはなぜでしょうか。マルチスレッドではないのでしょうか。 

同じ接続に対して複数のスレッドが同時に異なるコールを処理し、キューに入れると私たちは想定していました。しかし、リバースエンジニアリングの結果、実際のフローは少し異なることがわかりました。

このコードは、コールがディスパッチされる直前に、必要に応じて新しいスレッドをスピンし、OSF_SCONNECTION::TransAsyncReceive を呼び出します。TransAsyncReceive は、同じ接続に対する要求を受信しようとし、その後、新しいスレッドに要求を送信します（CO_SubmitRead を呼び出します）。 

もう一方のスレッドは TppWorkerThread からの要求を拾い、最終的に  ProcessReceiveComplete になり、MaybeQueueThisCall を呼び出して、SCALL をディスパッチキューに入れます。その後、伝播してこの接続の新しい要求の受信が試行されます。 

結局、複数のスレッドが稼働していたとしても、実際にその接続に使用されているのは 1 つのスレッドだけです。つまり、複数のスレッドからコールを同時にキューに追加することはできません。

私たちは、1 秒あたりのコール数を増やして、この脆弱性のトリガーにかかる時間を最小限に抑える方法を探しました。そして、受信コードのリバースエンジニアリングをしている時に、 パケットの長さがパケット内の実際の RPC 要求よりも大きい場合、RPC ランタイムが残りを保存することに気が付きました。その後の新しい要求のチェック時には、ソケットをすぐに使用することはできません。まず、パケットの「残り」があるかどうかをチェックし、残りがあれば、その残りから新しい要求を処理します。

これにより、送信するパケット数を大幅に少なくし、各パケットに最大数の要求を入れ込むことが可能になりました。このとおりに実行してみたところ、キューに追加される 1 秒あたりのコール数はそれほど変わらず、あまり効果はないようでした。