ESP-IDFのESP-TEEに重大な脆弱性、5.5.6で修正
ESP-IDFのESP-TEEに、通常側のアプリから信頼側のメモリを壊せる脆弱性が見つかりました。ESP32-C5など4種のチップでESP-TEEを使う組織は、版を確認し、5.5系は5.5.6へ更新してください。
急ぎ度: 早めに
CVSS v3は9.3で重大ですが、悪用にはデバイス上で通常側のアプリを動かす必要があり、KEVの掲載は確認できず、公表は昨日で、5.5系には修正版があります。
関係があるか
ESP32-C5、ESP32-C6、ESP32-C61、ESP32-H2の機器で、ESP-TEEによる通常側と信頼側の分離に頼っている組織が対象です。ESP-TEEを使わない構成が影響を受けるかどうかは、ベンダーの告知で確認してください。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| ESP-IDF 5.5系 | 5.5.5 | 5.5.6 |
| ESP-IDF 6.0系 | 6.0.4より前（下限の版はベンダーの告知で確認） | 6.0.4（修正予定） |
| ESP-IDF 6.1系 | 6.1.1より前（下限の版はベンダーの告知で確認） | 6.1.1（修正予定） |
確かめ方
- 1製品に使っているチップがESP32-C5、ESP32-C6、ESP32-C61、ESP32-H2のいずれかか、部品表や設計資料で確認します。
- 2プロジェクトでESP-TEEを有効にしているか、ビルド設定とファームウェアの構成を確認します。
- 3ビルドに使っているESP-IDFの版を確認します。出荷済みの機器は、どの版でビルドしたファームウェアが載っているかを、リリース記録から追います。
何が起きたか
ESP-IDFのESP-TEEに、通常側のアプリケーションが信頼側（TEE）専用のメモリへ書き込めてしまう脆弱性が見つかりました。通常側と信頼側を分けるはずの境界が破れ、信頼側の処理が壊れるおそれがあります。
ESP-IDFはEspressifのIoT開発フレームワークです。問題は、通常側から信頼側へ処理が移る入り口にあります。この入り口は、通常側が渡したスタックポインタをそのまま使って、レジスタの内容を書き込みます。しかも、信頼側のスタックに切り替える前、ポインタを検証する前に書き込んでいました。セキュアサービスの呼び出しと割り込みの両方の経路が、この順序になっています。
書き込み先を信頼側のメモリに向けられると、制御の流れを決めるデータが壊れ、コード実行、サービス停止、システムのクラッシュにつながる可能性があります。CWEは範囲外書き込み（CWE-787）などに分類されています。
攻撃の流れ
-
1
通常側で実行
デバイス上で、権限のない通常側アプリが動いている状態から始まります。
-
2
信頼側へ遷移
セキュアサービスの呼び出しか割り込みで、処理が信頼側の入り口に入ります。
-
3
検証前に書込
入り口が、通常側の指定したスタックポインタを検証せずにレジスタの内容を書き込みます。
-
4
TEEメモリ破壊
信頼側専用のメモリが書き換わり、制御データの破壊や停止につながります。
どう悪用されるか
悪用にはデバイス上で通常側のアプリケーションを動かせることが前提で、攻撃元はローカルです。認証や特別な権限は要らず、利用者の操作も要りません。ネットワークから直接届く脆弱性ではありませんが、機器に不審なアプリを載せられる経路があれば前提を満たします。
成功すると、信頼側のメモリが書き換えられます。TEEが守っているはずの情報や処理に影響が及び、機密性・完全性・可用性のいずれも大きく損なわれる、というのがCVSSの評価です。信頼側がクラッシュすれば、機器全体が止まることもあります。
今すぐやること
-
1
対象のチップと構成を洗い出す
ESP32-C5、ESP32-C6、ESP32-C61、ESP32-H2を使う製品のうち、ESP-TEEを有効にしているものを一覧にします。信頼側で鍵や認証を扱う製品を先に見ます。
-
2
ビルドに使っているESP-IDFの版を確認する
開発環境で、実際にビルドに使う版を確認します。5.5.5を使っていれば対象です。6.0系と6.1系は、6.0.4と6.1.1より前かどうかを見ます。
idf.py --version -
3
5.5系は5.5.6に更新して再ビルドする
ESP-IDFを5.5.6に更新し、ファームウェアを再ビルドします。出荷済みの機器には、OTAなど既存の更新手段で配布します。
-
4
6.0系と6.1系は告知で修正版の公開を確認する
6.0.4と6.1.1は修正予定とされています。公開状況と、影響する版の下限は、EspressifのGitHubにあるセキュリティアドバイザリで確認してください。公開されたら速やかに更新します。
-
5
通常側で動かすコードの出どころを見直す
サードパーティ製のアプリや、機器の利用者が追加できるコードの有無を確認します。修正版を配布するまでは、信頼できないコードを載せる経路を増やさないようにします。
背景
ESP-TEEは、ESP-IDFが備える信頼実行環境の仕組みです。通常側（REE）のアプリと、鍵や認証情報などを扱う信頼側（TEE）を分け、通常側のコードに不具合や悪意があっても、信頼側には届かないようにします。今回の脆弱性は、その分離そのものを破ります。
特権の高い側が、低い側から渡されたポインタを使う前に検証しない問題は、OSのシステムコールなどでも知られた型です。今回は、入り口の処理順序が問題です。信頼側のスタックへ切り替える前に、通常側の指定した場所へ書き込んでしまいます。通常側のアプリを自社で完全に管理できる製品ほど影響は小さく、第三者のコードを載せる製品ほど影響が大きくなります。
よくある質問
Q.脆弱性の説明に出てくる「ESF-IDF」は、ESP-IDFとは別のものですか。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
ESF-IDF is the Espressif Internet of Things (IOT) Development Framework. From 5.5.5 until 5.5.6, 6.0.4, and 6.1.1, the esp_tee trap entry in esp_tee_vectors_plic.S and esp_tee_vectors_clic.S saves a caller-controlled register frame through the REE-supplied stack pointer before switching to the trusted TEE stack or validating the pointer. A local unprivileged REE application can direct this machine-mode write into TEE-exclusive memory on ESP32-C5, ESP32-C6, ESP32-C61, and ESP32-H2 devices, breaking the REE/TEE isolation boundary and potentially corrupting TEE control-flow data for code execution, denial of service, or system crashes. Both secure-service ecall and interrupt entry paths contain the vulnerable ordering. This issue is fixed in version 5.5.6 and is scheduled to be fixed in versions 6.0.4 and 6.1.1.
出典: CVE.org (CVE Program・cvelistV5) NVD