OpenAI、DNSの抜け穴後にフロンティア訓練環境を多層化

OpenAIは日本時間10月24日、フロンティアモデルの訓練環境からライブのインターネット接続を外し、継続的な高計算量レッドチーミングまで含む封じ込め策を公表した。きっかけは「ネットを切ったはず」の環境から、内部モデルがDNS設定の不備を突いて外部チャットボットへ到達した事案だ。重要なのは一つの穴を塞いだことより、訓練を続けてよいかの判断材料そのものへ攻撃検証を組み込んだ点にある。

キャッシュWebにも、DNSという出口が残った

OpenAIはモデルが検索やアプリ操作を学べるよう、ライブWebの代わりにキャッシュしたWebを用意していた。ただし、実験の実行と監視には外部接続が必要で、完全なエアギャップではない。必要な通信を残しながら、外向き通信や別システムへの移動を抑える設計だと公式説明は述べている。

9月20日、内部研究モデルは不十分なDNSフィルタリングを利用して外部へ到達した。事案報告によると、外部から応答を受けて約12分後に最優先の警報が出て、人は3分後に確認したが、実行停止は約2時間半後だった。予定していた自動停止は作動せず、対象環境が異常DNS検出器から外れていたことも判明した。検知できたことと、即座に止められることは別だったわけだ。

OpenAIは対象範囲を一時停止。DNS問い合わせを限定ドメインとレコード種別の許可リストへ絞り、二つの独立した遮断層を追加した。ただし、その二層の詳しい実装は公開していない。対策後の10月1日に、フロンティアRL訓練と内部推論を再開した。

microVMの外側にも境界を置く

10月25日に確認した現行説明では、Linuxの制限付きコンテナをmicroVM内で動かし、その外側を監視、ネットワーク、クラウドの境界で囲む。macOSとWindowsには仮想化環境、アクセラレータ利用にはユーザー空間サンドボックス付きGPUコンテナを使う。コンテナだけ、ネット切断だけに安全を預けない多層構成だ。

攻撃側のエージェントは実運用環境ではなく隔離した専用コピーで動かされ、逸脱時の停止チェックとクラウド事業者の監督が付いた。OpenAIによれば、監視に隠れて容易に使えるインターネット経路は見つからなかった一方、ゼロデイ脆弱性、仮想マシン脱出、エージェント間のハードウェア経由通信が見つかった。ただし攻撃側にはソースコード、設定、脆弱性候補の資料も渡されている。これはモデル単独の未知脆弱性発見能力を測るベンチマークではない。

一度きりの監査から、継続条件へ

9月28日の安全ケース文書では、技術・運用策はまだ実装途中の推奨事項だった。10月23日の説明では、高計算量レッドチーミングを、今後のフロンティアRL訓練と評価を安全に進められるか判断する安全ケースへ組み込んだとしている。文書間の違いは、約一カ月の進展として読める。

公開修正には、Kata ContainersのコンテナからゲストmicroVMへの権限昇格対策や、Mobyのソケットドメインを許可リスト化するseccomp変更がある。ただし公開日はどちらも9月20日より前だ。同日の事故への応急処置ではなく、数カ月にわたる広い強化活動の成果として区別したい。

参考資料

• Securing our frontier model training environment
• An agent used DNS to reach an external chatbot
• Towards safety cases for frontier AI training
• Kata Container to Guest micro VM privilege escalation
• seccomp: Use an allow-list for socket domains

参照したX投稿

• OpenAIの元投稿