Eclair legt zwei Fehler offen, die Lightning-Knoten abstürzen ließen
Serguey Asael Shinder2 Min. LesezeitZwei weitere Denial-of-Service-Schwachstellen in Eclair, der Lightning-Implementierung von ACINQ, wurden am 1. Oktober auf Delving Bitcoin offengelegt. Beide lagen im Ablauf der Kanaleröffnung und sind in Eclair v0.14.1 behoben, veröffentlicht am 29. Juli; Betreibern wird v0.14.1 oder neuer empfohlen. Bereits am 24. September waren zwei andere Eclair-Fehler offengelegt worden, die in v0.14.0 behoben sind.
Der erste war eine Race Condition. Eclair weist eine doppelte temporary_channel_id zurück, indem es die Kanaltabelle des Peers prüft – doch zwischen dieser Prüfung und dem Eintragen des neuen Kanals vergeht Zeit. Wer mehrere identische open_channel-Nachrichten hintereinander schickt, bringt zwei davon an der Prüfung vorbei, und Eclair startet zwei Kanal-Akteure für eine ID. Der zweite überschreibt den ersten in der Tabelle; zurück bleibt ein verwaister Akteur mit etwa 25 KB, bis der Peer die Verbindung trennt. Wiederholt verliert der Knoten laut Offenlegung rund 1 MB pro Sekunde, bis zum Speicherüberlauf oder einer Garbage-Collection-Spirale, die ihn vom Netz nimmt. Matt Morehouse fand den Fehler mit seinem Fuzzer smite, der meldete, dass Eclair manchmal zwei open_channel-Nachrichten mit derselben ID annahm.
Der zweite umging den Begrenzer gegen gefälschte Kanäle, der die Zahl unbestätigter Kanäle deckelt. Indem der Angreifer die endgültige ID jedes Kanals als temporäre ID des nächsten open_channel wiederverwendete, zählte der Begrenzer eine ID doppelt und entfernte dann beide Einträge zugleich – sein Zähler stieg nie über zwei, während die echten offenen Kanäle unbegrenzt wuchsen. Jeder Kanal speichert eine Kopie der init-Features des Peers; auf etwa 65 KB aufgebläht, kostete jeder Kanal so viel Speicher. Laut Offenlegung brachte eine einzige Verbindung ohne On-Chain-Kosten einen Knoten mit 4 GB Heap in etwa 48 Minuten zum Speicherüberlauf. Weil die Kanäle gespeichert werden, stürzte der Knoten bei jedem Neustart erneut ab, bis jemand den Heap vergrößerte oder die Zeilen von Hand löschte. Gefunden wurde das laut dem Autor dieses Berichts mit einem LLM-gestützten Werkzeug, das die Einstiegspunkte einer Codebasis und ihre Invarianten erfasst und gegen die BOLT-Spezifikationen prüft; bestätigt und den Proof of Concept gebaut habe er selbst.
Warum das wichtig ist
Der Fehler mit gespeicherten Kanälen ist der schwerere: Ein Knoten, der bei jedem Neustart abstürzt, braucht einen Betreiber, der von Hand eingreift. Und wie bei der Offenlegung der Vorwoche sind die Werkzeuge zur Fehlersuche inzwischen halb Fuzzer, halb Sprachmodell – weitere solche Berichte über Lightning-Implementierungen sind zu erwarten.