if-forget/cve-2026-52134-libiec61850libiec61850 v1.6 の GOOSE リプレイ処理に影響する CVE-2026-52134 に関する公開技術勧告および再現エビデンス。
CVE-2026-52134 が割り当てられました。対応する CVE レコードの公開は保留中です。
src/goose/goose_receiver.cparseGoosePayload()libiec61850 v1.6 の GOOSE サブスクライバ受信パスは、サブスクライバから見える状態を更新し、登録済みリスナーコールバックを呼び出す前に、特定のリプレイまたは古い GOOSE メッセージを適切に拒否しません。
2 つの制御された実験は、同じ受信パスにおける関連する動作を示しています:
stNum へのロールバック: サブスクライバが stNum=2 を処理した後、以前にキャプチャした stNum=1 フレームをリプレイすると、リスナーが古い状態とデータを再度報告しました。sqNum のリプレイ: 同じ stNum であるが古い sqNum を持つ以前にキャプチャしたフレームをリプレイすると、そのフレームは無効とマークされましたが、リスナーコールバックは依然として発生し、リプレイされたデータは見えたままでした。これらは、2 つの別々の CVE ではなく、1 つのリプレイ/メッセージ鮮度処理の問題に関する 2 つの関連する観察結果として提示されています。
攻撃者は以下を実行できる必要があります:
0x88B8 を使用してイーサネットフレームを注入するこれは、任意のインターネットベースのリモート攻撃ではありません。
関連する受信ロジックは、受信した stNum が保存されている stNum と等しい場合に sqNum をチェックします。テストされたコードパスは、サブスクライバ状態が更新され、リスナーが呼び出される前に、より低い stNum を拒否しません。
テストされたライブラリファイルは変更されていません。src/goose/goose_receiver.c のオリジナルと作業用コピーは同じ SHA-256 値を持っていました:
c42f2aec80f605c458d0bca524ccb09f2e35f9b83a02f854f95d9444616c075b
veth0 / veth1 分離された仮想イーサネットペアtcpdumpテストハーネスは制御された状態遷移を生成し、コールバックから見える stNum、sqNum、有効性、およびデータ値を出力しました。脆弱なライブラリファイル自体は変更されていません。
制御されたパブリッシャーは 2 つの状態を送信しました:
State A: stNum=1, sqNum=0, data=1111
State B: stNum=2, sqNum=0, data=2222
ベースラインのパケットキャプチャには、この順序で 2 つの GOOSE フレームが含まれていました:
Frame 1: stNum=1, sqNum=0
Frame 2: stNum=2, sqNum=0
サブスクライバ出力には、State B の前に valid=false とマークされた stNum=1, sqNum=0 の補助コールバックも含まれていました。この補助コールバックは証拠に保持されていますが、ロールバックの結論の根拠としては使用されていません。決定的なリプレイ前状態は、stNum=2 とデータ値 2222 を含む後のコールバックでした。
リプレイスクリプトは 2 フレームのベースラインキャプチャを読み込み、フレーム 1 を選択し、veth0 を通じて 1 回送信しました。
リプレイの直前、リスナーは次のように報告していました:
stNum=2, sqNum=0, valid=true, allData={2222}
古いフレームが 1 回リプレイされた後、リスナーは次のように報告しました:
stNum=1, sqNum=0, valid=true, allData={1111}
これは、以前にキャプチャされた低い stNum のフレームをリプレイした後に、stNum=2 から stNum=1 へのサブスクライバ状態のロールバックが観察されることを示しています。
同じ古いフレームのコピーがさらに 4 つ送信されました。4 つすべてに stNum=1, sqNum=0 が含まれていました。
後のコピーは valid=false と報告されましたが、コールバック番号は増え続け、リプレイされたデータは表示されたままでした:
この二次的な観察は、繰り返されたフレームを無効とマークしても、テストされた受信パスにおけるリスナーへの配信を妨げなかったことを示しています。
初期の再現では、公式のサンプルパブリッシャーとサブスクライバが使用されました。パブリッシャーは通常のシーケンスを生成しました:
stNum=1
sqNum=0, 1, 2, 3
最初にキャプチャされたフレーム (stNum=1, sqNum=0) は、サブスクライバがすでに後のシーケンス値を処理した後にリプレイされました。
リプレイされたコピーは、受信した sqNum=0 が保存されたシーケンス値より新しくなかったため、無効と報告されました。ただし、サブスクライバはリプレイされたデータを含むリスナーイベントを出力し続けました:
この実験は、より限定的ではあるが関連する観察を裏付けています:
生の元のリプレイスクリーンショットは、補足資料として保持されています:
これらの生の画像には、無関係な Scapy オプションモジュールのインポート警告が含まれています。警告は、スクリプトがキャプチャされた GOOSE フレームを報告して送信を完了することを妨げませんでしたが、技術的な結果を確認するには、上記のより鮮明なスクリーンショットが推奨されます。
これらの実験は、同じ GOOSE リプレイ/メッセージ鮮度問題の異なる分岐を示しています:
| 観察 | 受信メッセージ | 観察された結果 |
|---|---|---|
低い stNum のリプレイ | 保存済み stNum=2; 受信した古い stNum=1 | テストした実行では、古い状態とデータがリスナーに配信され、有効として報告されました |
非増加 sqNum のリプレイ | 同じ stNum; 受信した古いまたは重複した sqNum | メッセージは無効と報告されましたが、リスナーコールバックとリプレイデータ配信は継続しました |
最初の観察は、新しい状態から古い状態へのロールバックを示すため、主要な CVE 発見事項です。2 番目の観察は、無効な同一状態のリプレイがリスナーパスを通じて継続する方法に関する裏付けとなる証拠です。
実証されたソフトウェアレベルの影響は次のとおりです:
stNum からより古い stNum に移動する可能性があります。独立した鮮度チェックなしでコールバックデータを消費するアプリケーションは、古い値またはリプレイされた値を処理する可能性があります。
下流への影響は、サブスクライバアプリケーション、構成、インターロックロジック、および保護ロジックに依存します。
これらの実験では、物理的な保護リレー、トリップ回路、遮断器、または実運用の変電所ネットワークはテストまたは操作されていません。
サブスクライバ状態を更新するか、リスナーを呼び出す前に:
stNum より古い受信 stNum を拒否します。stNum が変更されていない場合、非増加の sqNum を拒否します。stNum ロールバックと繰り返される sqNum 値を監視します。以下の画像は、来歴と環境情報を提供します。これらは再現を裏付けるものですが、主な結果を理解するために個別に必要なわけではありません。
実証された結果は、リプレイの受け入れと古い状態の配信です。これは、テストされた展開で暗号認証が有効であったことを証明することに依存しません。
報告者: