ai-gateway-payload-processingに脆弱性、認可不備
ai-gateway-payload-processingに、利用者が別のテナントのAPIキーを使ってLLMを呼び出せてしまう脆弱性が見つかりました。複数のテナントや部門でAIゲートウェイを共有している組織が対象です。まず自社の構成が当てはまるかを確認し、Red Hatの告知を見ながら修正版の適用に備えてください。
急ぎ度: 早めに
CVSS v3が9.1で重大と評価されていますが、悪用の確認や修正版の情報は現時点で見当たらないため、構成の確認から早めに始める段階と考えます。
関係があるか
複数のテナントや部門が共通のゲートウェイ経由でLLMを使い、各テナントのAPIキーを共有の保管場所に置いている環境が対象です。単一テナントで使っている場合は、影響が及ぶ範囲は限られるとみられます。
| 製品 | 影響を受ける版 | 直った版 |
|---|---|---|
| ai-gateway-payload-processing | 影響する版はRed Hatの告知で確認してください | 修正版はRed Hatの告知で確認してください |
確かめ方
- 1自社のAIゲートウェイやLLM基盤の構成資料を開き、ai-gateway-payload-processingが組み込まれているかを調べます。製品名で見つからないときは、Red Hat系のAI基盤を導入した担当部署かベンダーに確認します。
- 2組み込まれている場合は、複数のテナントや部門が同じゲートウェイを共有しているか、各テナントのAPIキーを共有のストアから取り出す構成かを確認します。
- 3Red Hatのセキュリティ情報ページで、自社が使っている版が影響範囲に入るかを照らし合わせます。
何が起きたか
ai-gateway-payload-processingに、他のテナント向けのAPIキーが勝手に使われてしまう脆弱性が見つかりました。その結果、別のテナントが契約しているLLMの利用枠を、第三者が消費できてしまいます。
このサービスは、リクエストに含まれるモデルの識別子などをもとに、使う認証情報を選びます。ところが、その識別子を送ってきた利用者に権限があるかを、サービス内で確認していません。共有のストアから取り出した対象テナントのAPIキーが、そのままリクエストに付けられます。
弱点の型としては、利用者が指定した値で参照先が決まる認可の不備にあたるCWE-639に分類されています。
攻撃の流れ
-
1
正規の認証
ゲートウェイを使える利用者として認証を通ります。
-
2
他テナントを指定
リクエストの中で、自分のものではないテナントのモデルを指定します。
-
3
認可確認なし
サービスは権限を確認せず、共有ストアから対象テナントのAPIキーを取り出します。
-
4
キーを付けて転送
取り出したAPIキーが付いたリクエストが、LLMの提供元へ送られます。
-
5
他社の枠を消費
別のテナントのLLM利用枠とクォータが使われます。
どう悪用されるか
悪用にはゲートウェイを使える認証済みのアカウントが必要です。ネットワーク越しに実行でき、特別な条件は要らず、被害を受ける側の操作も不要とされています。
悪用されると、別のテナントのAPIキーで不正なリクエストが送られ、そのテナントのLLM利用枠とクォータが使われます。想定外の利用料の発生や、本来の業務で枠が足りなくなるといった形で表に出ます。CVSSでは影響範囲が変わるものと評価され、機密性への影響は高、完全性と可用性への影響は低とされています。
今すぐやること
-
1
導入状況と構成を洗い出す
ai-gateway-payload-processingを使っているシステムと、共有しているテナントや部門の範囲を整理します。
-
2
Red Hatの告知を確認する
影響する版と修正版、回避策が出ていないかを、Red Hatのセキュリティ情報ページとBugzillaの該当票で確認します。
-
3
修正版に更新する
修正版が公開されていれば、検証環境で動作を確かめたうえで本番に更新します。
-
4
利用状況を見直す
ゲートウェイのログと、LLM提供元の利用量・請求の画面で、身に覚えのない呼び出しや急な消費がないかを確かめます。とくに、自分のテナントに属さないモデルへの呼び出しがないかを見てください。
すぐ更新できないとき
公式の回避策は確認できていません。恒久的な対策ではありませんが、修正版を当てるまでの間は、ゲートウェイの前段で、利用者ごとに使えるモデルを制限する認可を重ねる方法があります。あわせて、テナントごとにLLM提供元側の利用上限を設定しておくと、被害の広がりを抑えられます。
背景
AIゲートウェイは、社内の各アプリやチームが外部のLLMを呼び出すときの窓口です。窓口にAPIキーを預けておけば、各アプリがキーを持たずに済み、利用量の管理も一か所で行えます。そのぶん、窓口が誰にどのキーを使わせるかの判断を誤ると、複数のテナントの契約と費用に一度に影響します。
今回の脆弱性は、キーを預かる側が、リクエストを送った利用者の権限を確かめないまま取り出す点にあります。LLMの利用枠は従量課金や上限で管理されることが多く、被害は情報の漏えいだけでなく、費用の増加や業務の停止という形でも現れます。
よくある質問
Q.部門ごとにゲートウェイを分けずに使っているだけでも当てはまりますか。
まだ分かっていないこと
- 影響する版と修正版の番号、公式の回避策は、まだ確認できていません。Red Hatの告知で最新の状況を確認してください。
- 実際の攻撃での悪用が確認されているかどうかは、公表されていません。
- 対象テナントのAPIキーそのものが攻撃者に読み出せるのか、リクエストに付与されて使われるだけなのかは、はっきりしていません。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 直った版 |
|---|---|---|---|
| Red Hat | Red Hat OpenShift AI (RHOAI) | — | — |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
A flaw was found in ai-gateway-payload-processing. An authenticated remote attacker can exploit this vulnerability by submitting a request specifying another tenant's model identifier in the request body or header. Because the service does not verify authorization before retrieving credentials from the shared store, it injects the target tenant's application programming interface (API) keys into the request. This flaw allows an attacker to perform unauthorized requests and consume another tenant's large language model (LLM) resources and quotas.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- web access.redhat.com
- web bugzilla.redhat.com
- web nvd.nist.gov
- web github.com