OpenMAIC 1.0.2、DNSリバインディングとクラウドメタデータへのSSRFを修正し、クラスルームの上書きも防止

オープンソースのマルチエージェント教育プラットフォームOpenMAICは9月14日、ネットワークリクエストによって悪用可能な3件の問題を修正したバージョン1.0.2をリリースした。最も重大な2件は、いずれも`/api/proxy-media`および共通の外部URL防御機構に存在していた。1件目は拒否リストの適用順序に誤りがあり、Alibaba Cloudのインスタンスメタデータアドレス`100.100.100.200`がIPリテラルとして検査を通過してしまう問題。2件目は典型的なDNSリバインディングで、プログラムは最初にホスト名を解決して検証するものの、実際に`fetch()`を実行する際に再び名前解決していたため、攻撃者は2回の問い合わせの間に応答をパブリックIPから内部ネットワークのアドレスへ変更できた。[公式変更履歴](https://github.com/THU-MAIC/OpenMAIC/blob/main/CHANGELOG.md)によると、新バージョンではメタデータ、マッピング、エンコーディング変換を先に検査したうえで、共通のpinned dispatcherを介し、防御機構が実際に検証したアドレスだけに接続する。リダイレクトの各ホップにも同じルールが適用される。

3件目の脆弱性は`POST /api/classroom`に存在していた。従来は呼び出し元がクラスルームIDを指定でき、一時ファイルの名前変更時に既存のクラスルーム内容が上書きされる可能性があった。1.0.2ではIDをサーバー側で生成し、ファイルを排他的に作成する。衝突した場合は回数を制限して再試行し、それでも解決しなければHTTP 409を返す。これは単なる一般的なWeb脆弱性ではない。OpenMAICはユーザーに代わってモデル、検索サービス、メディアサービスを呼び出し、セルフホスト環境では通常、プロバイダーのAPIキーを保持している。SSRFがクラウドメタデータサービスに到達すれば、さらにワークロード認証情報を取得される可能性がある。

アップグレードには互換性の変更も伴う。クライアントが指定した`stage.id`は無視されるようになる。また、`100.64.0.0/10`のCGNATアドレス帯はデフォルトでブロックされるため、Tailscaleなどのオーバーレイネットワークを介してローカルのモデルやメディアホストへ接続している環境では、`ALLOW_LOCAL_NETWORKS=true`を明示的に設定する必要が生じる可能性がある。一部のIANA予約済みアドレス帯、ドキュメンテーション用アドレス帯、ブロードキャストおよびマルチキャストのアドレス帯は無条件で拒否される。運用担当者はアップグレード後、内部モデルのエンドポイント、リダイレクトチェーン、APIクライアントを改めてテストし、ローカルネットワークへのアクセス許可によってプロキシのSSRF攻撃対象領域が再び拡大しないことを確認すべきだ。