AI エージェントを VM に入れれば安全か?

no extension

昨今は「AI の暴走」が話題だが,我らが Bruce Schneier 先生の記事経由で,以下の記事を紹介してみる1

ものすごく簡単に要約すると,既製の VM は高機能 AI エージェントの隔離手段として十分ではなく,VM に対する攻撃面(attack surface)を減らすか環境全体での多層防衛が必要という内容である。

you can no longer assume a mere VM will contain a sufficiently advanced AI agent. To use a 2010s term of art, you should treat such agents as an advanced persistent threat.

条件及び課題は以下の通り(Kagi Assistant による要約)。

項目 内容
AIエージェント GPT 5.6-Cyber
仮想化環境 QEMU/KVM
ゲストOS Debian Linux 12
CPU環境 AMD Zen 3
課題 VMから脱出し,ホスト側に置かれたフラグファイルを読み取るCTF形式の課題
エージェントの権限 VM内では任意の操作が可能
接続方法 SSHでVMへ接続

実験上の重要な点は,AIエージェントをVMの中から起動したのではなく,VMの外側で起動し,SSH経由でVMを操作させたことです。エージェントはVM内で自由にコマンドを実行できましたが,ホスト側には直接アクセスできない設定でした。

今どきの AI エージェントの凄いところは,幾つものサブエージェントを並行して起動し,失敗を修正しつつ試行錯誤を繰り返し,持ってる知識と知り得る情報を駆使し,目標達成のためなら手段を選ばないところにある。

The agent searched diligently and backtracked from multiple paths that led to failure. First it tried identifying what was accessible via the network on the host; it found a CUPS server (with a known CVE that had not made it to oldstable packages), but was not able to complete exploitation due to AppArmor. It then detected I run my host kernel with mitigations=off and attempted to use hardware bugs to get a read oracle of host memory (the primitive was too unreliable).

Eventually it went on a bug-hunting analysis of the host kernel source, QEMU, and associated libraries. It slowly chained together multiple vulnerabilities, including several 0-day bugs, until it could craft a reliable VM escape.

「手段を選ばない」には人間社会の倫理観に反する行動も含まれる。 そもそもハッキングは人間社会という文脈と盤面を引っくり返す行為で,その対象はシステムやルールのみならず倫理にも及ぶ(まさに米国トランプ政権が派手にやってることだ)。 人間様がやってるんだから AI がやらないわけがない(笑)

GPT 5.6-Cyber は実験中に3回 VM からの脱出に成功したらしい(以下も Kagi Assistant による要約)。

1回目:JanusCapeの利用

最初の脱出では,JanusCapeと呼ばれる脆弱性,CVE-2026-53359が使われました。

この種の攻撃は,VMやエミュレーターがゲストOSから受け取るデータを適切に検証しないことを利用します。ゲスト側から細工した入力を送り,QEMUなどホスト側で動作するコンポーネントに異常な処理をさせることで,ゲストの権限を越えてホスト側の処理へ到達します。

2回目:libslirpと未割り当てバグの組み合わせ

2回目の脱出では,QEMUのネットワーク機能に関連するlibslirpのCVE-2026-9539と,まだCVE番号が割り当てられていないバグ修正コミットが組み合わされました。これにより,ホストメモリの任意の読み取りと書き込みが可能になったとされています。

この事例は特に示唆的です。単一の脆弱性を突いただけでなく,次のような攻撃チェーンを構成しています。

  1. ネットワーク処理に存在する脆弱性を利用する
  2. 追加の不具合や修正前の挙動を組み合わせる
  3. 本来アクセスできないホスト側のメモリへ到達する
  4. メモリの読み書きを通じて,さらに権限を拡大する

3回目:複数の0-dayを含む脆弱性チェーン

3回目には,複数の0-dayを含む脆弱性チェーンが使われました。

0-dayとは,開発者や防御者が十分に把握・修正できていない脆弱性を指します。ここで重要なのは,AIが単に公開済みの脆弱性データベースを検索しただけではない点です。実験結果が示すところでは,AIエージェントはソフトウェアの挙動を調べ,未知の問題を発見し,それらを連鎖させて脱出に利用しました。

これは,AIエージェントを「既知の攻撃コードを実行する自動化ツール」とみなすだけでは不十分だということを意味します。

さて,このように多彩な攻撃ができるようになった AI エージェントを如何に封じ込めて制御するか,あるいは攻撃から防御するか。 記事では既製の VM では不十分だと主張している。

An off-the-shelf VM is not enough to contain a modern, cyber-capable AI agent. There is simply too much attack surface. Even innocuous features (like running with a display) add extra, exploitable attack surface.

VM については,最小限の攻撃面とセキュリティに重点を置いて意図的に設計された仮想化技術を使うべきとしている。 その上で,最小特権,ログの取得,アクティブな監視,エージェントの操作時間の制限,使用ごとに環境をクリーンアップすること,などを推奨している。

A start is using a virtualization technology that was purposely built with a minimal attack surface and a focus on security, like Firecracker. I had the AI agent run against Firecracker. It was able to hardlock the machine due to more Linux kernel flaws (all patched in upstream), but could not successfully escape. It may have, given even more time, but Firecracker is obviously a substantially harder target. In general, we have to become much more attentive to security fundamentals: least privilege (regarding network access, credentials, available features, etc.), logging, and active monitoring. Further, we can limit the time agents have to operate and ensure a pristine environment for each use.

もちろん OS を含むディストリビューションの更新は必須なのだが,その運用は従来よりシビアになるかもしれない。 記事の筆者は,今となっては古い Debian 12 を好んで使っているそうだが(安定志向),上流のアップデートを即時に受けられないため,脆弱とみなしているようだ。

A distribution with rapid updates is now a requirement. I love older, stable software, but the cycle of backporting patches is simply too long. An older distribution (like Debian 12, my old standby) that isn’t getting immediate upstream updates should be assumed vulnerable. A competent agent will discover these bugs quickly and synthesize target-specific exploits.

セキュリティ・サポートが継続されているから OK とはならないということだ。

思うのだが,脆弱性を溜めるだけ溜め込んで気が向いたときにだけアップデートを提供する macOS や,対応する脆弱性の優先順位が不明で発見者がシビレを切らして公開してしまう Windows なんかはどうなんだろうねぇ。 あとは財務的な支援を受けにくく脆弱性の発見と対策が後手に回りがちな FOSS 製品は,ますます厳しい状況になるかもしれない。

ブックマーク

参考

thumbs
ハッキング思考 強者はいかにしてルールを歪めるのか、それを正すにはどうしたらいいのか
富裕層、権力者、急成長企業はシステムをハッキングして成功した。AI時代にルールを味方につけるには、「正しいハッキングの考え方」が必要だ。
 
Release 2023-10-16
評価     

[Comment] Kindle 版あり

Powered by linkcard


  1. 今回紹介した記事を含むブログの更新は Mastodon の @trailofbits@infosec.exchange でも確認できる。 ↩︎