The Windows IOCTL Census: A Corpus-Scale, Multi-Architecture Database of the Driver Control-Code Surface

技術要約：Windows IOCTL センスス（The Windows IOCTL Census）

問題提起
Windows のデバイス制御パスは、権限のないプロセスが I/O コントロール（IOCTL）コードを介してカーネルメモリに到達できる、極めて重要な攻撃対象領域（アタックサーフェス）を構成している。チェックされていないバッファ長などの脆弱性は、権限昇格を許容する。セキュリティコミュニティには、特定の脆弱性を見つけるためにドライバーを記号実行するスキャナー（例：ScrewedDrivers、POPKORN、ioctlance）や、既知の悪質なドライバーを追跡するキュレーションリスト（例：LOLDrivers）が存在するが、ドライバーエコシステム全体にわたる制御コードのディスパッチ・サーフェスの体系的かつ永続的なマップは存在しない。既存の記号実行ツールは、パス爆発、高い偽陰性率、およびアーキテクチャ上の制限という課題を抱えている。特に、出荷されているドライバー群の約半分を占め、「脆弱なドライバーの持ち込み（BYOVD）」攻撃で頻繁に悪用される 32 ビット（x86）ドライバーに対しては、しばしば失敗する。さらに、これらのツールは通常、一度限りの検出リストを出力して構造データを破棄するため、ドライバー間のクロス分析や再評価を行うことができない。

手法
著者らは、27,087 個の署名済み Windows ドライバーのコーパスを Recover（回収）、Enrich（拡充）、Rank（順位付け） の 3 つのステージで処理する、決定論的かつアーキテクチャ中立的なパイプラインである Windows IOCTL センスス を提案している。

1. Recover（決定論的パス）:

   • アーキテクチャ: このステージでは記号実行を一切行わない。代わりに、glaurung フレームワークを使用して、ドライバーバイナリをアーキテクチャ中立的な中間表現（IR）へとリフトアップする。
   • ディスパッチ回収: IRP_MJ_DEVICE_CONTROL ハンドラを特定し、比較定数とジャンプテーブルを解析することで制御コードをデコードする。このアプローチにより、x64 および x86 アーキテクチャの両方においてディスパッチサーフェスの回収に成功している。
   • 構造解析: x64 ドライバーについては、インタープロシージャルなコールグラフを構築し、ディスパッチルーチンからの到達可能性解析を実行し、軽量なテイント解析を実行する。テイントソースはバッファ入力ポインタ（Irp->AssociatedIrp.SystemBuffer）であり、これをシンク（デリファレンスまたはストア）まで追跡することで、未検証の制御入力の特定を行う。
   • プロベナンス（由来）: PE メタデータ、Authenticode 署名情報、およびデバイスセキュリティ記述子（SDDL）を抽出し、寛容なアクセス制御リスト（ACL）を持つドライバーをフラグ立てする。
   • 制約: 解析はドライバーのサイズ（4MB を超えるドライバーの完全な逆アセンブルをスキップ）およびアーキテクチャによって制限される（x86 は、独立した検証オラクルが欠如しているため、サーフェスのみの解析となる）。

2. Enrich (モデル・パス):

   • 標的化: このステージは、寛容なデバイス記述子を持ち、かつ少なくとも 1 つの未検証のバッファ入力シンクを含むディスパッチルーチンを備えたドライバーの、限定的な高優先度サブセットに対してのみ実行される。
   • LLM の統合: 大規模言語モデル（LLM）に対し、コンパクトな特徴量サマリー（デバイス記述子、デコードされたコード、テイントシンクの詳細、および逆アセンブルの抜粋）をプロンプトとして与え、構造化された判定を生成させる。判定にはリスクレベル、プリミティブ型（例：境界外書き込み）、および根拠が含まれる。モデルには、ハルシネーション（幻覚）を避けるために、生のデコンパイルされたバイト列を見せないよう明示的に指示されており、決定論的な事実に基づいている。

3. Rank (クエリ・インターフェース):

   • システムは、リレーショナルビューを通じてデータを提供する。主要なビューには、未検証のシンク数によってユーザー到達可能なハンドラをランク付けする「ハント」ビュー、ベンダー間で共有される制御コードをグループ化する「クロスドライバー」ビュー、および静的なテイント結果と取り込まれた記号実行の結果を比較する「オラクル合意」ビューが含まれる。

主な貢献

• 公開・クエリ可能なデータベース: 著者らは、27,087 個のバイナリ、310 万個のデコード済み制御コード、818 万個の関数、および 1,595 万個のコールエッジを含むデータセットを公開している。
• アーキテクチャ中立的なカバレッジ: 記号実行ではなく IR リフティングを使用することで、記号実行ツールが通常中断してしまう 32 ビットの x86 半数を含む、コーパスの 80%（21,708 個のドライバー）のディスパッチサーフェスを回収した。
• 構造の永続性: 以前のツールとは異なり、このセンススは構造を検出後に破棄せず、コールグラフ、テイントシンク、およびデコードされたコードを保持する。これにより、「この特定の制御コードを共有するドライバーはどれか？」や「どのハンドラが長さチェックなしでコピーシンクに到達するか？」といったクエリが可能になる。
• ハイブリッド検証: 静的なテイント解析と記号実行の結果（ioctlance による）を統合して、知見を相互検証する。これにより、両方の手法が補完的な盲点（例：静的テイントは METHOD_NEITHER コードを見逃すが、記号実行はパス爆発に苦しむ）を持っていることを実証している。

結果

• カバレッジ: 決定論的パスにより、21,708 個のドライバー（コーパスの 80.1%）のディスパッチサーフェスを回収した。x64 ディープレーンでは、818 万個の関数と 63,263 個のバッファ入力テイントシンクが得られた。
• フィルタリングの効率: 決定論的なフィルタ（寛容な記述子 ＋ 未検証のシンク）により、27,087 個のドライバーを LLM による拡充のための 330 個の候補ハンドラへと絞り込んだ。
• モデルの性能: LLM は、拡充された 329 個のハンドラのうち 135 個を「クリティカル」、159 個を「ハイ」と判定した。著者らは、これらは真の陽性率ではなく、あくまで優先順位付けの仮説であることを強調している。
• 手法間の合意: 1,000 個のドライバーのサンプルを用いた ioctlance との比較において、両手法は記号実行エンジンによってフラグが立てられたドライバーの 65% で一致した。不一致の主な原因は、精度エラーではなく、記号エンジンが特定のハンドラに到達できなかったこと（到達可能性の天井）に起因していた。
• バックテスト: 既知の CVE および LOLDrivers カタログに対するバックテストでは、ランキングがその範囲内で効果的であることが示された（例：nvlddmkm.sys 内の既知の脆弱なハンドラが上位 0.14% にランクされた）。しかし、バッファ入力のテイントソースとは異なるメカニズムで入力が取得されるフレームワークドライバー（WDF/KMDF）における脆弱性は、本システムでは見逃された。

意義と主張
本論文は、新たなバグの存在を証明する脆弱性検出器としてではなく、Windows ドライバーの制御コード・サーフェスの基礎的なマップとしての意義を主張している。

• 検出からナビゲーションへの転換: 著者らは、限られたリバースエンジニアリングのリソースを優先させるために、コミュニティには攻撃対象領域の持続的かつクエリ可能な記録が必要であると主張している。このセンススにより、研究者は運や手選りのターゲットに頼ることなく、出荷されているドライバーの「ロングテール」をナビゲートできるようになる。
• アクセスの民主化: 構造データ（デコード、コールグラフ、到達可能性）を公開する一方で、二重用途（デュアルユース）の悪用を防ぐために、特定の標的層（テイントシンクとモデルの判定）は非公開とすることで、ドライバーセキュリティ解析への参入障壁を下げることを目的としている。
• 相補性: 本研究は、決定論的な回収と記号実行が相補的であることを示している。センススは、これらの手法が互いの盲点をカバーし合えるような構造的コンテキストを提供する。
• 今後の展望: 著者らは、x86 および arm64 に対するテイント解析の欠如、METHOD_NEITHER およびダイレクト I/O パスの除外、および実行時に適用されるデバイス記述子の処理能力の欠如といった限界を認めている。彼らは、このセンススを、コア部分を再構築することなく新しいアナライザ（フレームワークドライバーや物理メモリプリミティブ用など）を追加できる、拡張可能な生きたインフラストラクチャとして位置づけている。