KVMレジスタ操作によるFirecrackerマイクロVMのエスケープ

セキュリティ研究者らは、サーバーレスコンピューティングプラットフォームを支えるオープンソース仮想化技術であるFirecrackerにおける重大な脆弱性を実証しました。特定のカーネル遷移中に保存されたCPUレジスタを操作することで、ホストマシン上でroot権限によるコード実行を達成しました。2026年11月に詳細が公開されたこのエクスプロイトは、ゲスト仮想マシン内の攻撃者が、標準的な監視ツールにアラートを発生させたりVMをクラッシュさせたりすることなく、そのVMを管理するホストプロセスを制御することを可能にするものです。

何が起きたか

PWN.AI Security Researchとして発表を行った研究チームは、「PwnEscape」シリーズの第2弾をリリースしました。本作業は、以前に開示された、ゲストが選択したホスト物理メモリを読み書きできるメモリープリミティブに基づいています。今回のフォローアップでは、このプリミティブと、ホスト上のFirecrackerプロセスの実行中状態を検出・変更する技術を組み合わせました。対象は、Linuxカーネル7.0.0-1011-awsを搭載したx86-64システムで動作するFirecrackerバージョン1.16.1です。

このエクスプロイトは、従来のバッファオーバーフローやアプリケーションロジック内のソフトウェアバグには依存していません。代わりに、ゲストVMとホストユーザー空間プロセス間の切り替え時に、Linuxカーネルがプロセッサの状態を保存および復元するメカニズムを悪用しています。KVMの出口処理中にホストスレッドのレジスタが格納される正確なメモリ位置を特定することで、攻撃者は実行フローをリダイレクトしました。これにより、ホストプロセスにwriteシステムコールを実行させ、標準エラー出力へ特定のマーカー文字列を表示させました。重要なのは、ペイロードの実行後、エクスプロイトが元のレジスタ値を復元し、Firecrackerプロセスが正常に継続実行できるようにした点です。VMはSSH経由でアクセス可能なままであり、ホストカーネルにはエラーが記録されませんでした。

仕組み

攻撃の中核は、仮想CPU（vCPU）がホストとどのように相互作用するかを理解することに依存しています。FirecrackerマイクロVM内の各vCPUは、ホストプロセス内のスレッドに対応します。ゲストが割り込み処理やエミュレーションハードウェアへのアクセスなど、ホストの介入を必要とする操作を行う場合、スレッドはKVMカーネルモジュールから退出し、ユーザー空間に戻ります。この退出時、カーネルは命令ポインタやスタックポインターを含むスレッドの現在の状態を、pt_regsと呼ばれる構造体に保存します。

攻撃者は既存のメモリアクセスプリミティブを使用し、これらの保存されたレジスタ構造体を探してホスト物理メモリをスキャンしました。まず、既知のゲストページに一意のバイトパターン（ノンス）を配置しました。拡張ページテーブル（EPT）を辿ることで、ゲスト物理アドレスをホスト物理アドレスに変換しました。次に、ホストページテーブルを逆マッピングして、どのホストプロセスがその物理ページをマップしているかを特定し、アドレス空間レイアウトランダム化（ASLR）にもかかわらず、Firecrackerプロセスとそのメモリレイアウトを効果的に識別しました。

プロセスが識別されると、彼らはKVM_RUN ioctl呼び出しから戻るスレッドの期待される状態と一致するpt_regsフレームを検索しました。候補の検証は、保存された命令ポインタを既知のFirecrackerコードアドレスと比較し、システムコール引数がアクティブなKVMリクエストと一致することを確認して行いました。正しいフレームを特定した後、保存された命令ポインタをFirecrackerバイナリ内のwriteラッパーに向けるように変更し、スタックポインタを調整してペイロード引数を含めました。ゲストがシリアルポートへの書き込みによってKVMの出口トリガーを発動すると、ホストスレッドは攻撃者制御のアドレスで再開し、書き込みを実行した後、慎重に構築された戻りシーケンスを通じて元のパスに戻りました。

主要な詳細

• ターゲット環境: x86-64上のFirecracker v1.16.1、ホストカーネル7.0.0-1011-aws、ゲストカーネル6.18.44+。
• 特権レベル: テストインスタンスはjailerや名前空間制限なしで直接rootとして起動されたため、エクスプロイトはrootとしてのコード実行を達成しました。
• ステルス性: エクスプロイト後もVMは完全に稼働状態を維持しました。SSH接続は持続し、稼働時間カウンタも通常通り進みました。
• メモリープリミティブ: この攻撃には、ゲスト内から特定のホスト物理メモリページを読み書きできる事前の能力が必要です。
• 検証: 研究者らは、ホストプロセスのstderrからマーカー文字列N8V23M2\nを捕捉し、実行可能テキストや共有ライブラリが変更されていないことを確認することで成功を検証しました。
• 回復: エクスプロイトは実行後に明示的に3つの変更されたスタックワードを復元し、一時的なスタック領域に即時のフォレンジック痕跡を残しません。

なぜ重要か

サーバーレスプラットフォームや隔離コンテナ環境を構築するエンジニアにとって、このデモンストレーションは、セキュリティのためにハイパーバイザー境界だけに頼ることのリスクを浮き彫りにします。Firecrackerは高密度の隔離用に設計されていますが、このエクスプロイトは、ゲストがメモリ分離層を突破できれば、管理スレッド自体をハイジャックできることを示しています。これは特に危険です。なぜなら、攻撃はサービスをクラッシュさせないため、標準的な可用性モニタリングでは検出が困難だからです。

影響は展開構成に大きく依存します。研究者らは、テストセットアップではseccompフィルタやユーザー名前空間などの追加封じ込め層なしでFirecrackerをrootとして実行していたと指摘しています。本番環境では、これらの制御により、仮にコード実行を達成しても攻撃者ができることが制限されます。しかし、VMMプロセス内で実行フローをリダイレクトできる能力は依然として深刻な脅威であり、攻撃者がシステムコール引数を操作したり、許可されたメモリ空間内のガジェットチェーンへジャンプしたりできれば、seccompポリシーを回避する可能性があります。

対策

• 特権レベルの監査: Firecrackerプロセスがrootとして実行されていないことを確認してください。組み込みのjailerを使用して権限を下げ、起動直後にファイルシステムアクセスを制限してください。
• seccompフィルタの有効化: Firecrackerプロセスで利用可能なシステムコールを制限するために厳格なseccompプロファイルを設定し、潜在的なコード実行に対する攻撃面を削減してください。
• ユーザー名前空間の使用: Firecrackerをユーザー名前空間内で実行し、プロセスをホストのrootユーザーから隔離して、エスケープの影響を限定してください。
• 異常な挙動の監視: VMMプロセスからの予期しないstderr出力や異常なシステムコールパターンのログを実装してください。ただし、このエクスプロイトはステルス性を考慮して設計されています。
• 最新情報の追跡: Firecrackerプロジェクトからの更新を追跡し、メモリ分離やKVM相互作用処理に関するパッチが入手可能になり次第適用してください。
• メモリープリミティブの見直し: ワークロードがゲストに対してホスト物理メモリマッピングをどのように公開しているかを調査し、不正な変換ルックアップに対してこれらのインターフェースを強化してください。