Cocos AIで別の機械の証明が通る脆弱性、0.9.0で対処
機密計算でAIを動かすCocos AIの0.8.2以前に、想定と別の機械の証明が通ってしまう脆弱性が公表されました。利用組織は0.9.0へ更新し、そのうえで許可する機械を固有のIDで限定してください。
急ぎ度: 早めに
CVSS v4は9.1と高いものの、悪用には前提条件が多く、一方で0.9.0への更新だけでは解消しないため、更新と設定の見直しを早めに済ませたい脆弱性です。
関係があるか
Cocos AIの0.8.2以前を使い、検証側が自分の管理外のものを含む複数のプラットフォームの証明を信頼している環境が対象です。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| Cocos AI（ultravioletrs/cocos） | 0.8.2以前 | 0.9.0（ただしソースコードの修正だけでは解消しないとされています） |
確かめ方
- 1運用中のCocosのリリース版を確認し、0.8.2以前かどうかを見ます。
- 2検証側（verifier）が、どのプラットフォームの証明を受け入れる設定かを洗い出します。
- 3証明の評価時に、機械の固有ID、許可された所有者、失効の有無を確認する設定があるかを見ます。Intel TDXなら、PCK証明書のPIIDを照合しているかが目安です。
何が起きたか
Cocos AIの0.8.2以前では、AIの処理を任せる機械が想定どおりの相手かを確認する仕組みに穴があり、別の機械が出した正規の証明でも受け入れてしまいます。その結果、検証側は誤った機械を認可します。
Cocos AIは、ファームウェアのパッチレベルとソフトウェアの測定値が期待どおりで、証明が正しく検証できれば、受け入れていました。どの機械が出した証明か、許可された所有者のものか、失効していないかは確かめていません。分類はCWE-346で、CVSS v4は9.1（critical）です。
0.9.0で対処されましたが、ソースコードの修正だけでは完全には解消できません。
機密計算の脅威モデルそのものから生じる問題だからです。筆者は、悪用に必要な前提が重く、すぐ止めるべき種類ではないと見ています。ただ、更新して終わりにせず、信頼する機械を絞る運用までセットで考える必要があります。
攻撃の流れ
-
1
別の機械を掌握
攻撃者が、同じ検証側に信頼されている別のプラットフォームを制御または侵害します。
-
2
正規の証明を用意
その機械が出す、有効な証明を手に入れます。
-
3
証明を差し替え
本来の機械の証明の代わりに、別の機械の証明を提示します。
-
4
検証が通る
ファームウェアと測定値が一致するため、出所を問われずに受け入れられます。
-
5
誤った機械を認可
検証側が、想定外の機械を信頼できる相手として扱います。
どう悪用されるか
ネットワーク越しに攻撃でき、事前の権限も利用者の操作も要りません。ただし攻撃の難度は高く、同じ検証側が信頼する別のプラットフォームを、攻撃者が制御または侵害していることが前提です。
悪用されると、検証側は誤った機械を認可し、そこへ渡したデータや処理の機密性と完全性が損なわれます。CVSSの評価では、可用性への影響はなく、ほかのシステムへの波及も想定されていません。
今すぐやること
-
1
Cocosを0.9.0へ更新する
運用中の版が0.8.2以前なら、0.9.0に更新します。0.9.0には、同じ証明付きTLSの別の脆弱性（CVE-2026-33697）の修正も含まれます。ただし本件はこの更新だけでは解消しません。
-
2
検証側が信頼する範囲を棚卸しする
検証側が証明を受け入れているクラウド、拠点、テナントを洗い出します。不要なものは信頼から外し、残すものは管理者がだれかを確認します。
-
3
許可する機械を固有のIDで絞る
更新後も、許可する機械を固有のIDで限定する運用を続けます。許可リストにはワークロードの持ち主が責任を持ち、物理的な攻撃から守られていると分かっている機械だけを載せます。
-
4
ベンダーの告知で自社の構成を確かめる
Intel TDX以外の環境、たとえばAMD SEV-SNPで使う場合の許可リストの作り方は、CocosのセキュリティアドバイザリとTEEを提供する事業者の案内で確認します。
すぐ更新できないとき
アドバイザリは、サポートするTEEの固有のハードウェアID（Intel TDXならPlatform Instance IDentifier、PIID）の許可リストを、明示的に作る方法を挙げています。ワークロードの持ち主が、物理的な攻撃から守られていると分かっているIDだけを載せます。証明の評価時に、PCK証明書のPIIDがリストのどれかと一致することを確認し、他のTEEの証明が通らないようにします。
背景
Cocos AIは、TEE（信頼実行環境）の中でAIの処理を動かし、データやモデルを持ち主以外から守るための仕組みです。利用者は処理を任せる前に、相手が期待どおりの環境かを、機械が出す証明で確かめます。この証明をTLSの接続に組み込んだものが、attested TLSです。今回の問題は、その確認が「どの機械か」まで見ていなかった点にあります。社員証の部署名と役職だけを見て、顔写真と照合しない受付に近い状態です。
Cocos AIは、同じ証明付きTLSの別の問題として、鍵の取り出しを前提にした中継攻撃（CVE-2026-33697）も0.9.0で修正しています。本件を見つけて報告したのはTU DresdenのMuhammad Usama Sardar氏で、ProVerifという検証ツールで形式的に解析しています。アドバイザリは、Cocosに限らない技術的な背景として、同氏の論文「Identity Crisis in Confidential Computing: Formal Analysis of Attested TLS」を挙げています。
よくある質問
Q.Cocos以外の機密計算製品も、同じ問題を抱えていますか。
まだ分かっていないこと
- Intelが発表したPlatform Ownership Endorsements（POE）について、証明書の配布経路は未定で、現時点でこれを提供するクラウド事業者はありません。
- ハードウェアやクラウドの事業者から、完全で明確な仕様がまだ示されていません。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Cocos AI is a confidential computing system for AI. In version 0.8.2 and earlier, Cocos AI accepts trusted execution environment attestation Evidence when firmware patch levels and software measurements match, without binding the Evidence to an allowed platform owner or unique machine identity and without enforcing revocation. A remote attacker who controls or compromises another platform trusted by the same verifier can substitute valid Evidence from that platform and cause authorization of the wrong platform. This vulnerability is addressed in 0.9.0. However, this vulnerability can't be patched in source code alone, since the vulnerability arises from the confidential computing threat model itself.
出典: CVE.org (CVE Program・cvelistV5) NVD