RunSybilが、悪意あるモデルテンプレートを介したコード実行を実証。Pythonは、サンドボックス脱出はセキュリティ脅威モデルの対象外だとしている。
RunSybilのセキュリティ研究者によると、CPythonのメモリ安全性に関する欠陥により、悪意あるAIモデルのテンプレートがコードサンドボックスを突破し、推論サーバー内で任意のコードを実行できる可能性があります。
RunSybilのセキュリティ研究者Darius Houle氏は、同社のブログ記事で次のように述べています。「この脆弱性を悪用すれば、攻撃者は何百万ものユーザーリクエストを処理するサーバーの内部に足場を築けます。そうしたワークロードをホストするクラウドインフラそのものを直接攻撃することも可能です」
研究者らは、細工したモデルによってこの欠陥を悪用し、Jinjaのサンドボックス保護を回避したうえで、モデルの提供処理中にコードを実行できることを実証しました。Jinjaは、ユーザーとLLMのやり取りを構造化するために使われる、Pythonベースのテンプレートエンジンです。この攻撃は、顧客が独自のモデルをアップロードして実行できるAIホスティング事業者に影響を及ぼす恐れがあります。複数の顧客のリクエストを処理するインフラ内部に、攻撃者が足場を築く可能性もあると、同記事は指摘しています。
一方、CPythonに関するセキュリティ報告を扱うPython Security Response Team（PSRT）は、CSOの取材に対し、今回の実証が示すセキュリティ上の影響に異議を唱えました。同チームは次のように述べています。「RunSybilが報告したCPythonの根本的なバグは認識しており、修正に貢献してくれたことに感謝します。しかし、実証されたサンドボックス脱出をCPythonのセキュリティ脆弱性とは考えていません」
意見の対立の焦点は、サンドボックス脱出の防止をインタープリターが担うべきかどうかです。RunSybilは、この欠陥がAI推論インフラにリスクをもたらすと主張しています。これに対しPSRTは、信頼できないPythonコードをサンドボックス内で実行することは、CPythonのセキュリティ脅威モデルの範囲外だとしています。
Pythonの型処理メカニズムを悪用
Houle氏は次のように記しています。「私たちが発見したバグは、CPythonによるジェネリック型の処理を悪用して、サンドボックスを突破するものです。この悪用には、空のサンドボックスコンテキストであっても、あらゆるテンプレートでサンドボックスが利用可能にしているオブジェクトを使いました」
研究者らは、オブジェクトがコールバックによって変更された後でも、CPythonがキャッシュ済みのパラメーターリストを使い続けることがあると突き止めました。その後、インタープリターが新たに導入されたパラメーターを元のリストから探すと、無効なインデックスを受け取る場合があります。この状態を検出するために設計されたアサーションは、通常のリリースビルドでは無効化されています。そのため、インタープリターが想定された範囲外のメモリにアクセスできてしまいます。
RunSybilはこの挙動を利用して、サンドボックスがアクセス不能に保つはずだったPythonオブジェクトへの参照を取得しました。
Houle氏は次のように記しています。「無効なアドレスを参照すれば、通常はインタープリターがクラッシュします。しかし、有用な生きたPythonオブジェクトを指すアドレスであれば、コールバックがそのオブジェクトへの参照を得られます。サンドボックス側はそのオブジェクトを公開するつもりがなくてもです」
研究者らはさらに、取得したオブジェクト参照を使い、実行可能なコードの構築に必要なPythonのクラスや関数にアクセスしました。
悪意あるモデルテンプレートでコード実行が可能に
攻撃を実証するため、RunSybilはモデル「Qwen2.5-0.5B-Instruct」を改変し、バックドア入りのchat_template.jinjaファイルを組み込みました。このモデルをvLLMなどの推論サービングエンジンで読み込んで使用すると、テンプレートによってサービング処理内で任意のコードが実行されました。
Houle氏は次のように記しています。「チャットテンプレートのサンドボックスを突破してコードを実行できることは、推論プロバイダー、ライブラリ開発者、モデル利用者のすべてを危険にさらすサプライチェーンリスクです」
研究者らによると、概念実証（PoC）のエクスプロイトは、外部で入手したモデルを顧客がアップロードできるBYOM（Bring Your Own Model）機能に対応する複数の推論プロバイダーに共有したということです。
Pythonは脆弱性としての分類に異議
RunSybilはこの問題を、CPython、Jinjaを保守するPallets Project、そしてHugging Faceに報告しました。研究者らは、根本的な問題にどのプロジェクトが対処すべきかをめぐり、見解が食い違っていたと述べています。
CPythonは、信頼できないPythonコードのサンドボックス化をセキュリティ境界としてサポートしていないとの立場です。PSRTはCSOへの回答で、プロジェクトのセキュリティポリシーに言及しました。同ポリシーは、サンドボックスからの脱出は、影響を受けるサンドボックスソフトウェアの保守担当者が対処すべきだと定めています。
同チームは次のように述べています。「したがって、こうしたサンドボックスからの脱出は当方のセキュリティ脅威モデルの対象外であり、影響を受けるサンドボックスソフトウェアの保守担当者が対処すべきものです」
同チームはまた、連携した修正対応の仕組みが存在しなかったというRunSybilの指摘にも反論しました。研究者らは、CPythonが指定する非公開のGitHub脆弱性報告窓口ではなく、メールで報告を提出したのだといいます。
修正は3つのPythonブランチにバックポート
RunSybilはCPythonにパッチを提出し、8月14日にメインの開発ブランチへマージされました。PSRTによると、この修正はセキュリティ修正ではなく通常のバグ修正として、3.13、3.14、3.15の各ブランチにもバックポートされています。
この区別は重要です。RunSybilは、修正がサポート対象のすべてのPythonバージョンに行き渡らないのではないかと懸念していたためです。
研究者らは、Python 3.12へのバックポートがないため、AIインフラ全体で修正が採用されるまでに時間がかかる恐れがあると述べています。
Houle氏は次のように記しています。「AIエコシステムの主要部分はいまだにPython 3.12に強く依存しています。私たちのメモリ安全性の修正が自然に普及するのは、サポート終了を迎える2028年後半になるかもしれません」研究者らは、AIホスティング事業者に対し、サンドボックス化されたコード、テンプレートエンジン、式評価器は、単独のセキュリティ境界として頼るのではなく、ベストエフォートのセキュリティ対策として扱うよう推奨しています。
