Nitro Enclaves SDK for Cに2件の脆弱性｜0.4.6更新とイメージ再ビルドが必要

AWSは2026年10月30日、AWS Nitro Enclaves SDK for Cの脆弱性2件を公表しました。対象は0.4.5以前で、修正版は0.4.6です。SDKを取り込んだエンクレーブイメージを再ビルドする必要があります。親EC2インスタンス上のアプリケーションから隔離領域へ入力が渡る構成を優先して確認してください。

CVE-2026-119116はサンプルアプリケーションkmstool-enclaveのメモリー処理、CVE-2026-119148はSDKライブラリーのリージョン値検証に関係します。前者を使わないから両方対象外、あるいはEC2全体がインターネットから直接侵害される、といった一括判断は適切ではありません。本記事は11月2日に確認した公式告知に基づくニュース解説です。

隔離領域へ渡る入力が確認点

AWS Nitro Enclaves SDK for Cは、Nitro Enclaves内で動作し、暗号学的なアテステーションを用いてAWS KMSを呼び出すアプリケーション向けのライブラリーとサンプルツールです。AWS公式速報2026-157-AWSは、kmstool-enclaveとライブラリー部分で異なる問題があることを説明しています。

エンクレーブを採用していても、外部から受け取る値の検証が不要になるわけではありません。今回の2件では、親インスタンスで実行されるアプリケーションが渡すメッセージやリージョン文字列が問題になります。Webアプリケーションの秘密情報処理を隔離領域へ分離している担当者は、Web側とエンクレーブ側の担当をまたいで依存関係を確認する必要があります。

SetClientの問題はサンプルと派生コードが対象

CVE-2026-119116はkmstool-enclaveのSetClientコマンドハンドラーにおける解放後使用です。AWSは、親EC2インスタンス上のアプリケーションがvsockを通じて細工したメッセージを送ると、エンクレーブ内のヒープメモリーが破壊され、内部で任意コードを実行され得ると説明しています。一般のHTTP要求だけで直ちに成立する認証不要RCEとは区別してください。

対象になるのはkmstool-enclave、またはそれから派生したコードを含むイメージです。配布元のサンプルをコピーして名称を変えている場合は、製品名の検索だけでは導入を見落とすため、元コードとの関係も確認します。SDKを依存に含むことと、脆弱なサンプル処理を実行していることを分けて記録してください。

自社が独自実装へ置き換えた部分があるなら、どの処理が残っているかをコードとビルド定義で照合します。今回の資料だけで独自実装の安全性を保証することはできません。名称変更や一部改変を対象外の根拠にせず、対象処理が実行される経路を確認することを提案します。サンプルの利用状況が不明な環境も、確認待ちとして残します。

リージョン検証不備はライブラリー側の問題

CVE-2026-119148では、呼び出し元が指定したリージョン文字列からAWS KMSのTLSサーバー名を組み立てる際の検証が不十分でした。親インスタンス上のアプリケーションが細工した長い値を渡すことで、KMSのドメイン接尾辞が切り詰められ、エンクレーブが接続先証明書の真正性を誤って解釈する可能性があります。

AWSの個別勧告は、KMSエンドポイントになりすまして、攻撃者が選んだ鍵素材などの偽応答を注入できると説明しています。未検証の外部リージョン値をライブラリーへ渡すアプリケーションが影響を受けます。kmstool-enclaveを使わない構成でも、この条件を別に確認してください。サンプルの利用有無だけでは判定が終わりません。

同資料は、真正なKMS応答は別途暗号化されており危険にさらされないこと、クロスアカウントやクロステナントのアクセスはできないことも明記しています。今回の問題をKMSサービス全体の侵害や、他の顧客の鍵の取得と説明するのは誤りです。確認すべきなのは、偽の応答を正しい処理結果として扱う可能性です。

リージョン値が設定ファイルの定数なのか、親側の要求や外部入力から渡されるのかを整理すると、調査対象を具体化できます。ただし、値を固定しているように見えることだけで更新を不要とは判断しません。公式は回避策なし、更新が必要と案内しているため、入力経路の確認と修正版の準備を並行して進めることを勧めます。

SDKの取り込みとイメージ再ビルドを分ける

v0.4.6リリースは、SetClientのリージョン失敗時の解放後使用修正と、エンドポイントのホスト名構築前のリージョン検証を列挙しています。同リリースには暗号化コンテキストのJSON処理やエラー経路のポインター初期化などの変更も含まれます。修正公開と公表を確認した日を、攻撃開始日と混同しないようにします。

更新作業では、ソースツリーのタグ、ビルド時に参照するSDK、出来上がったイメージ、実際に起動しているイメージを対応付けます。開発端末でリポジトリを更新しても、CIが固定した旧版を取得する場合や、保管済みの旧イメージを再利用する場合は、本番の処理は切り替わりません。これは本サイトが提案する配備確認の着眼点です。

特に、親インスタンス側の更新と、エンクレーブ内の成果物更新を同じ作業として扱わないようにします。SDKを組み込んだ側のビルドをやり直し、修正済みイメージの識別情報と作成時刻を記録します。独自フォークを使う場合には、上流の版番号だけでなく、修正を取り込んだ差分をレビューする必要があります。

本番へ投入する前に、以前のイメージがどこから起動されるかも確認します。自動復旧、スケールアウト、定期ジョブ、手動の再起動手順が旧成果物を参照していると、対応後に脆弱な状態へ戻る可能性があります。稼働中の一台だけを直すのではなく、次に作られる環境が修正版を使うことも完了条件に含めることを提案します。

正常な入力と失敗時の処理を試験する

以下は公式が保証する試験手順ではなく、自社の検証計画を作るための提案です。まず検証用の鍵やデータを使い、正しいリージョンを指定した通常のKMS連携が動くことを確認します。暗号処理の結果だけでなく、親側から要求し、エンクレーブ側で処理し、結果を戻す一連の業務経路を対象にしてください。実機で検証済みという説明ではありません。

次に、設定不足や不正なリージョン値をアプリケーションがどう扱うかを確認します。本番で攻撃を再現する必要はありません。利用中のインターフェースが想定外の値を拒否するか、失敗を成功と区別できるか、エラー後の処理が適切かを検証環境で見ます。成功時だけを比較していると、入力検証やエラー経路に関係する変更を見逃します。

試験記録にはSDKの版、コードのリビジョン、イメージの識別情報、入力条件、期待する結果、実際の結果を残します。秘密鍵や平文の業務データを記録する必要はありません。検証に使った無害なデータと、結果を判断できるログの参照先を対応させることで、秘密情報を増やさずに再現性を確保できます。

依存関係の更新でビルドに失敗した場合は、その時点で完了扱いにせず、取得したSDKの版、ビルド定義、関連ライブラリーの制約を確認します。原因不明のまま無関係な依存まで広く更新すると、試験範囲が増えて切り分けにくくなります。修正を取り込む変更と、互換性のために必要な変更を対応票へまとめてください。

悪用状況と過去の影響を推測しない

今回確認したAWS速報と個別勧告は、具体的な被害件数や実環境での悪用確認を説明していません。構造化メタでも悪用状況は不明とします。悪用の記載がないことは攻撃が存在しない証拠ではなく、更新を後回しにする理由にもなりません。一方で、読者の環境が侵害されたと断定する根拠にもなりません。

すでに親インスタンスで不審なプロセス、予定外の入力、説明できない暗号処理結果などを把握している場合は、修正の適用と別に調査を進めます。本サイトからは、発生時刻、対象イメージ、実行された処理、関連ログを保全し、担当者へ引き継ぐことを提案します。更新は過去に受け取った応答を正当化したり、業務判断を自動で修復したりするものではありません。

過去の結果を再確認する必要があるかは、利用する鍵素材や処理の用途、親側入力の管理状況、残っている記録によって変わります。今回の資料だけで一律の鍵失効や全処理の再実行を公式要請として案内することはできません。確認できる範囲と不明な範囲を分け、業務責任者と対応範囲を決めてください。

対応完了は稼働中と作成元の両方で判断

担当者へ確認すべき結論は、kmstool-enclaveまたは派生コードの利用有無、外部リージョン値を渡す経路、SDK 0.4.6の取り込み、イメージ再ビルド、本番反映、通常処理と失敗時処理の確認です。二つの脆弱性を一つの条件へまとめず、コード実行と偽応答のそれぞれについて対象構成を記録します。

切り戻しを行う場合も、旧版へ戻したまま処理を続けてよいかを再判断する必要があります。復旧手順には、旧イメージへ戻す操作だけでなく、影響する機能の停止や処理の保留も含めて検討します。修正版が存在すること、ビルドが成功したこと、本番がその成果物を使っていることを順に確認するのが、今回の対応の要点です。

保守会社や別チームへ依頼する場合は、SDK更新の完了報告だけでなく、再ビルドしたイメージと実際の配信先が対応している証跡を求めます。アプリケーション担当がライブラリーを更新し、基盤担当が旧イメージを起動するような担当間のずれを防ぐためです。作業票には、配備担当、確認担当、次回の自動作成で使う成果物、未確認の環境を別々に記録してください。確認できていない環境が残る場合は、全体完了とせず対象範囲を明記します。