Eine Schwachstelle in Eclair, einer Bitcoin-Lightning-Implementierung, könnte es einem böswilligen Peer ermöglichen, einen ungepatchten Node zum Absturz zu bringen, ohne einen Kanal zu finanzieren oder eine On-Chain-Gebühr zu zahlen. Betroffen waren Nodes mit v0.14.0 oder älter. In einem Regtest-Proof-of-Concept brachte der Forscher Erick Cestari einen 4-GB-Java-Heap nach etwa 47 Minuten und 43 Sekunden zum Überlaufen. Bis dahin hatten sich 217.623 Zeilen in der Kanaldatenbank angesammelt. Die Einträge blieben auf der Festplatte und führten dazu, dass dem Node beim Start erneut der Arbeitsspeicher ausging.
Warum das wichtig ist
Eclair begrenzte die Zahl ausstehender Kanäle, die ein Peer eröffnen konnte. Uneinheitliche Prüfungen vorläufiger und endgültiger Kanal-IDs führten jedoch dazu, dass der Zähler nicht alle unfinanzierten Kanäle erfasste. Ein Angreifer konnte so gespeicherte Anfragen anhäufen und den Node mit Speicher- und Datenbanklast belasten. Der Angriff erforderte weiterhin Rechenleistung und Netzwerkverkehr, aber keine BTC, wie sie normalerweise zur Finanzierung eines Kanals eingesetzt werden.
Der Proof of Concept zeigt einen anhaltenden Ausfall eines verwundbaren Nodes, nicht einen Angriff im laufenden Betrieb oder die Zahl betroffener Betreiber. Die gemessene Zeit bis zum Absturz ist ein Laborergebnis, kein allgemeingültiger Richtwert. Die Schwachstelle wurde in v0.14.1 behoben, das im Juli vor der öffentlichen Bekanntgabe erschien.
Auswirkungen auf den Markt
Der Befund betrifft die Verfügbarkeit von Lightning-Nodes, nicht einen nachgewiesenen Verlust von Geldern. Ein separater Fehler bei gleichzeitig ablaufenden Kanaleröffnungen, ebenfalls in v0.14.1 behoben, ließ verwaiste Prozesse Ressourcen verbrauchen. Von diesem Fehler erholte sich der getestete Node nach einer Trennung oder einem Neustart. Für die anhaltende Überlastung der Datenbank gilt das nicht.
ACINQ empfiehlt wegen weiterer Sicherheitslücken ein Upgrade auf v0.14.3. Betreiber mit einer bereits überlasteten Datenbank müssen diese gesondert wiederherstellen. Cestari nannte als mögliche Maßnahmen, den Heap zu vergrößern oder gefälschte Kanaleinträge manuell zu entfernen. Wiederholte Neustarts löschen diese Einträge nicht.
Häufig gestellte Fragen
-
Warum kann ein Neustart eines betroffenen Eclair-Nodes den Betrieb nicht wiederherstellen?
Die unfinanzierten Kanaleinträge bleiben in der Datenbank. Wenn Eclair sie beim Start erneut lädt, kann dem Node wieder der Arbeitsspeicher ausgehen.
-
Muss für den Angriff ein Bitcoin-Lightning-Kanal finanziert werden?
Nein. Ein böswilliger Peer konnte gespeicherte Kanalanfragen anhäufen, ohne eine Finanzierungstransaktion zu veröffentlichen oder eine On-Chain-Gebühr zu zahlen. Rechenleistung und Netzwerkverkehr waren dennoch nötig.
-
Welche Eclair-Versionen waren betroffen, und welche behob die Schwachstelle?
Betroffen waren erreichbare Nodes mit v0.14.0 oder älter. Die Schwachstelle wurde in v0.14.1 behoben, das im Juli vor der öffentlichen Bekanntgabe erschien.
-
Was zeigte der Eclair-Proof-of-Concept?
Im Regtest ging einem 4-GB-Java-Heap nach etwa 47 Minuten und 43 Sekunden der Speicher aus; bis dahin hatten sich 217.623 Zeilen in der Kanaldatenbank angesammelt. Das belegt weder Angriffe im laufenden Betrieb noch eine allgemeingültige Zeit bis zum Ausfall.
-
Warum empfiehlt ACINQ v0.14.3, obwohl v0.14.1 diese Schwachstellen behob?
v0.14.3 behebt weitere Sicherheitslücken. Die Korrektur der beiden Denial-of-Service-Schwachstellen in v0.14.1 ist daher keine umfassende aktuelle Sicherheitsempfehlung.
WuBlockchain
CoinTelegraph
CZ Binance
CoinDesk
Crypto News