if-forget/cve-2026-52134-libiec61850Öffentlicher technischer Sicherheitshinweis und Reproduktionsnachweise für CVE-2026-52134, das die GOOSE-Replay-Behandlung in libiec61850 v1.6 betrifft.
CVE-2026-52134 wurde zugewiesen. Die Veröffentlichung des zugehörigen CVE-Eintrags steht noch aus.
src/goose/goose_receiver.cparseGoosePayload()Der Empfangspfad des GOOSE-Subscribers in libiec61850 v1.6 lehnt bestimmte wiederabgespielte oder veraltete GOOSE-Nachrichten nicht ausreichend ab, bevor der für den Subscriber sichtbare Zustand aktualisiert und der registrierte Listener-Callback aufgerufen wird.
Zwei kontrollierte Experimente zeigen zusammenhängendes Verhalten im selben Empfangspfad:
stNum: Nachdem der Subscriber stNum=2 verarbeitet hatte, führte das erneute Abspielen eines zuvor erfassten stNum=1-Frames dazu, dass der Listener den älteren Zustand und die älteren Daten erneut meldete.sqNum: Wenn ein zuvor erfasster Frame mit demselben stNum, aber einem älteren sqNum erneut abgespielt wurde, wurde der Frame als ungültig markiert, aber Listener-Callbacks traten weiterhin auf und die wiederabgespielten Daten blieben sichtbar.Diese werden als zwei zusammenhängende Beobachtungen eines einzigen Problems bei der Replay-/Nachrichtenfrische-Behandlung dargestellt, nicht als zwei separate CVEs.
Ein Angreifer muss in der Lage sein:
0x88B8 einzuschleusenDies ist kein beliebiger internetbasierter Remote-Angriff.
Die relevante Empfangslogik prüft sqNum, wenn das empfangene stNum dem gespeicherten stNum entspricht. Der getestete Codepfad lehnt ein niedrigeres stNum nicht ab, bevor der Subscriber-Zustand aktualisiert und der Listener aufgerufen wird.
Die getestete Bibliotheksdatei wurde nicht modifiziert. Das Original und die Arbeitskopien von src/goose/goose_receiver.c hatten denselben SHA-256-Wert:
c42f2aec80f605c458d0bca524ccb09f2e35f9b83a02f854f95d9444616c075b
veth0 / veth1 unter LinuxtcpdumpDer Testaufbau erzeugte kontrollierte Zustandsübergänge und gab die im Callback sichtbaren Werte für stNum, sqNum, Gültigkeit und Daten aus. Die verwundbare Bibliotheksdatei selbst wurde nicht modifiziert.
Der kontrollierte Publisher sendete zwei Zustände:
State A: stNum=1, sqNum=0, data=1111
State B: stNum=2, sqNum=0, data=2222
Der Baseline-Paketmitschnitt enthielt zwei GOOSE-Frames in dieser Reihenfolge:
Frame 1: stNum=1, sqNum=0
Frame 2: stNum=2, sqNum=0
Die Subscriber-Ausgabe enthielt außerdem einen zusätzlichen Callback für stNum=1, sqNum=0, der vor State B als valid=false markiert war. Dieser zusätzliche Callback ist in den Beweismitteln enthalten, wird aber nicht als Grundlage für die Rollback-Schlussfolgerung verwendet. Der entscheidende Zustand vor dem Replay war der spätere Callback mit stNum=2 und dem Datenwert 2222.
Das Replay-Skript lud den Baseline-Mitschnitt mit zwei Frames, wählte Frame 1 aus und sendete ihn einmal über veth0.
Unmittelbar vor dem Replay hatte der Listener gemeldet:
stNum=2, sqNum=0, valid=true, allData={2222}
Nachdem der alte Frame einmal erneut abgespielt wurde, meldete der Listener:
stNum=1, sqNum=0, valid=true, allData={1111}
Dies zeigt ein beobachtetes Rollback des Subscriber-Zustands von stNum=2 auf stNum=1, nachdem ein zuvor erfasster Frame mit niedrigerem stNum erneut abgespielt wurde.
Vier weitere Kopien desselben alten Frames wurden gesendet. Alle vier enthielten stNum=1, sqNum=0.
Die späteren Kopien wurden als valid=false gemeldet, aber die Callback-Nummern stiegen weiter an und die wiederabgespielten Daten blieben sichtbar:
Diese sekundäre Beobachtung zeigt, dass das Markieren eines wiederholten Frames als ungültig die Zustellung an den Listener im getesteten Empfangspfad nicht verhinderte.
Eine frühere Reproduktion verwendete den offiziellen Beispiel-Publisher und -Subscriber. Der Publisher erzeugte eine normale Sequenz mit:
stNum=1
sqNum=0, 1, 2, 3
Der zuerst erfasste Frame (stNum=1, sqNum=0) wurde dann erneut abgespielt, nachdem der Subscriber den späteren Sequenzwert bereits verarbeitet hatte.
Die wiederabgespielten Kopien wurden als ungültig gemeldet, weil das empfangene sqNum=0 nicht neuer war als der gespeicherte Sequenzwert. Der Subscriber gab jedoch weiterhin Listener-Ereignisse mit den wiederabgespielten Daten aus:
Dieses Experiment stützt eine engere, aber verwandte Beobachtung:
Die rohen ursprünglichen Replay-Screenshots sind als unterstützendes Material aufbewahrt:
Diese rohen Bilder enthalten für das Experiment irrelevante Warnungen zum Import optionaler Scapy-Module. Die Warnungen verhinderten nicht, dass das Skript die erfassten GOOSE-Frames meldete und die Übertragung abschloss. Für die Überprüfung des technischen Ergebnisses sind jedoch die oben gezeigten saubereren Screenshots zu bevorzugen.
Die Experimente zeigen verschiedene Zweige desselben GOOSE-Replay-/Nachrichtenfrische-Problems:
| Beobachtung | Empfangene Nachricht | Beobachtetes Ergebnis |
|---|---|---|
Replay mit niedrigerem stNum | Gespeichert stNum=2; empfangen altes stNum=1 | Alter Zustand und alte Daten wurden an den Listener übermittelt und im getesteten Lauf als gültig gemeldet |
Replay mit nicht steigendem sqNum | Gleiches stNum; empfangen älteres oder doppeltes sqNum | Nachricht wurde als ungültig gemeldet, aber Listener-Callbacks und die Zustellung wiederabgespielter Daten liefen weiter |