EV充電通信実装における脆弱性の発見とSLACの技術的考察

最近、PlaxidityXのリサーチチームにより新たな脆弱性（CVE-2025-27071）が発見されました。本脆弱性は、EVと充電ステーション間の通信実装における重大な欠陥を明らかにするものです。これは、SLACプロトコルのオープンソース実装であるopen-plc-utilsに存在するスタックベースのバッファオーバーフローの脆弱性で、電気自動車（EV）および充電設備（EVSE）の双方に影響を及ぼします。攻撃者がこれを悪用した場合、対象機器上で任意のコードを実行される恐れがあります。本件は、EV充電インフラにおける通信実装のサイバーセキュリティリスクを具体的に示す事例です。充電ネットワーク全体において、実装レベルでのセキュリティ対策を強化する必要があります。

EVの普及が加速する中、車両と充電ステーション間の安全な通信はこれまで以上に重要になっています。特にVehicle-to-Grid（V2G）の統合が進む現在、通信の信頼性と安全性はインフラ全体の安定運用を左右します。ISO 15118は、非対称暗号技術、認証、暗号化を通じてシームレスかつ安全な充電を実現するための国際標準ですが、これらのセキュリティ要件を実装レベルで確実に反映させることは容易ではありません。

本記事では、当社リサーチチームが発見したEVと充電ステーション間の通信プロトコル実装における重大な脆弱性（CVE-2025-27071）について解説します。このバッファオーバーフローの欠陥により、対象機器上で攻撃者が任意のコードを実行できる恐れがあります。本件は2024年12月にQualcommへ報告され、その後セキュリティアドバイザリの公開、オープンソースプロジェクトに対するパッチ提供が2025年に実施されています。

背景：EVと充電ステーション間の通信における信頼性の重要性

EVでは、DIN SPEC 70121およびISO 15118で定義されたVehicle-to-Grid（V2G）プロトコル群に基づく高レベル通信が行われています。その通信手段として、Power Line Communication（PLC）が利用されています。特に商用の充電ステーションにおいては、EVと電力グリッドに接続された複数の充電設備との間で、認証、決済処理、充電スケジュールの調整といったデジタル通信を確立する必要があります。

このPLC通信の安定性と信頼性を担保するために用いられているのが、Signal Level Attenuation Characterization（SLAC）です。SLACはV2Gスタックに含まれるプロトコルの一つであり、電力線上のノイズや信号減衰の影響によって、EVが接続すべきではない充電ステーションと通信してしまうことを防ぐ役割を果たします。具体的には、IP通信を開始する前段階で、EVと充電ステーションの間でEthernetレベルのブロードキャストメッセージを数回やり取りし、ハンドシェイクを確立します。このプロセスにより、EVはグリッド内の充電設備を特定し、安定した通信経路を確立することが可能となります。

脆弱性の概要：オープンソースPLCファームウェアにおけるバッファオーバーフロー（CVE-2025-27071）

open-plc-utils は、Qualcomm Atheros Powerline Toolkitのオープンソース版として提供されているソフトウェアツール群です。plcboot(1) などのツールを通じて、AtherosおよびQualcomm製チップセットによるPLC機能の制御や操作を行うよう設計されています。また、EVおよびEVSE向けのSLACプロトコル実装も含まれています。EV側のSLAC機能は一般にRTOS環境（AUTOSARなど）上で実装されることが多い一方、Linuxベースで構築されたEVSEではopen-plc-utilsが利用されるケースが多くあります。

SLACプロトコルで定義されるメッセージの多くは固定長ですが、例外として信号減衰の測定値を含むメッセージは可変長となっています。EVが充電ステーションにPLC信号の減衰測定値を送信する際、通常は58個の周波数グループごとの減衰値が含まれます。減衰測定メッセージには、複数の減衰値が連続して格納されており、その末尾に「Number of Groups」という1バイトのフィールドが配置されています。このフィールドは、パケット内に含まれる減衰値の数を示します。例えば、この値が58であれば、58個分のデータがパケットに含まれていることを意味します。

当社リサーチチームが発見したのは、open-plc-utilsにおけるSLACプロトコル実装内のスタックベースのバッファオーバーフローです。本脆弱性は、EV側およびEVSE側の双方に存在していました。根本的な問題は、可変長配列のサイズを示す「Number of Groups」の値に対して適切な検証が行われていない点にあります。この値は入力検証されないまま、後続の memcpy 処理にそのまま使用されていました。その結果、攻撃者が意図的に異常なサイズ値を含むパケットを送信した場合、バッファ境界を超える書き込みが発生し、スタック領域が破壊される恐れがあります。

EV側への影響

EV側では、充電ステーション（EVSE）から送信される CM_ATTEN_CHAR_IND メッセージを受信・解析します。このメッセージには、EVSEからEVへ渡される可変長パラメータ「Number of Groups（NumGroups）」が含まれています。

問題となるのは、この NumGroups の扱いです。コード上では、受信メッセージを cm_atten_char_indicate 構造体としてキャストし、そこからNumGroupsの値を直接取得しています。そして、その値を境界チェックなしで直後の memcpy に使用しています。その結果、コピー先バッファ（この場合は session->AAG）のサイズを超えるデータが書き込まれる恐れがあり、バッファオーバーフローが発生します。
さらに重要なのは、session 変数がメイン関数のスタック領域に確保されている点です。

なお、実際に悪用の可能性はコンパイル環境（32bit／64bit、変数アラインメント、スタック配置など）やメモリ配置の条件に左右されます。本件では、攻撃者が制御可能なデータ量が最大255バイトである一方、影響を受ける構造体自体はそれ以上のサイズを持っています。そのため、単純にリターンアドレスを書き換える典型的な攻撃が直ちに成立するとは限りません。だからと言って、構造体内の他のフィールドを書き換えるなど、他の制御データを書き換えることで悪用される恐れは否定できません。

EVSE側への影響

EVSE側でも、EVと同様のパターンで脆弱性が確認されています。具体的には、パケット内の numGroups フィールドに対する境界チェックが欠落しており、その結果としてバッファオーバーフローが発生する恐れがあります。該当箇所は evse_cm_mnbc_sounds 関数内で確認されています。EVSE側では、受信した減衰特性メッセージからデータをスタック上のサイズ58バイトのバッファにコピーする処理において、攻撃者が操作可能な numGroups の値が境界チェックなしに forループの繰り返し回数として使われていました。

この関数におけるスタック使用量は、おおむね255バイト未満と見積もることができ、スタック上に確保されるメモリ領域が比較的小さいため、攻撃者が操作できるデータによって重要な制御情報に到達しやすい構造になっています。そのため、EV側と比べて悪用の可能性を想定しやすい状況にあると言えます。もちろん実際の攻撃成立可否は、コンパイル設定や保護機構（Stack Canary、ASLR、NXなど）、呼び出し規約、最適化の有無といった条件に左右されます。しかし、外部から与えられる値を検証せずにループ回数として使用する設計自体が、典型的なメモリ破壊バグの原因につながり得る設計であることは明らかです。

まとめ

open-plc-utilsプロジェクトにおけるSLACモジュールの最終更新は、2013年に遡ります。すでに12年以上が経過しており、現在のリソース制約が厳しいEV向け充電通信ECUにそのまま組み込まれている可能性は高くないかもしれません。しかしながら、本脆弱性の重要性が低いわけではありません。実際には、同モジュールは現在もLinuxベースの充電ステーションインフラで広く利用されているケースがあるためです。つまり、影響範囲は依然として現実的かつ実運用環境に直結しています。

なお、本脆弱性（CVE-2025-27071）はQualcommへ直接報告され、同社の内部PLCツールについても修正が実施されました。責任ある開示プロセスを通じて修正対応が行われたことは、エコシステム全体のセキュリティ強化に向けた重要な一歩といえます。

PlaxidityX サイバーセキュリティリサーチ＆ソリューションチームについて

PlaxidityXのサイバーセキュリティ リサーチ＆ソリューションチームは、自動車業界に特化したサイバーセキュリティの研究およびソリューション提供を行っています。車両アーキテクチャ、通信プロトコル、関連規格に対する深い理解を基盤に、包括的なサイバーセキュリティサービスを提供しています。

チームは、車両エコシステム全体を対象としたセキュリティ評価・ソリューションに取り組んできました。これまでに主要自動車メーカーおよびTier 1サプライヤーと多数のペネトレーションテストおよび研究プロジェクトを実施し、実環境を想定した検証を通じて設計上の課題抽出と改善支援を行っています。また、UN R155やISO 21434といった国際規制・標準への対応支援を含め、開発プロセス全体に組み込まれたセキュリティ体制の構築をサポートしています。

リサーチプロジェクトの実施から、PlaxidityXの先進的な製品導入まで、進化する脅威に対応するための知見と技術を提供し、車両ライフサイクル全体にわたるセキュリティ確保を支援します。