Eclair 0.14 behebt zwei Fehler, mit denen jeder Peer einen Knoten lahmlegt
Victoria Shinder2 Min. LesezeitZwei Denial-of-Service-Schwachstellen in Eclair, der Lightning-Implementierung von ACINQ, hat der Sicherheitsforscher Matt Morehouse am 24. September auf Delving Bitcoin offengelegt. Beide sind in Eclair v0.14.0 behoben; Betreiber von v0.13.1 oder älter sollten aktualisieren.
Die erste, LNF-2026-0001, steckte in der Verarbeitung von Feature-Vektoren - den Bitfeldern, mit denen Lightning-Knoten in der ersten init-Nachricht mitteilen, welche Protokollfunktionen sie unterstützen. Eclair las diese Bit für Bit und legte pro Bit mehrere Heap-Objekte an. Laut Offenlegung verursachte eine einzige init-Nachricht maximaler Länge rund 300 MB Speicherumsatz und blockierte einen Parser-Thread bis zu 300 ms; eine Flut solcher Nachrichten konnte binnen einer Minute alle Peers eines Opfers trennen und binnen fünf Minuten seinen Speicher erschöpfen.
Die zweite, LNF-2026-0002, betraf Gossip-Abfragen zu Kanälen. Eclair akzeptierte noch zlib-komprimierte query_short_channel_ids-Nachrichten, vier Jahre nachdem die Spezifikation BOLT 7 diese Kodierung abgeschafft hatte, und die Dekompression hatte keine Obergrenze. Eine 64-KB-Nachricht blähte sich auf 64 MB auf und wurde zu etwa 17 Millionen Heap-Objekten; ein Strom davon konnte einen Knoten binnen Sekunden vom Netz nehmen.
Wie sie gefunden wurden, gehört zur Geschichte. Die erste fand Morehouses Fuzzer smite im einfachsten Szenario: rohe Bytes als eine Nachricht senden und prüfen, ob das Ziel noch zügig auf einen Ping antwortet. Die zweite fand der Fuzzer nicht. Nach dem ersten Fehler ließ er eine LLM-gestützte Variantenanalyse über den Eclair-Code laufen, auf der Suche nach Stellen, an denen ein Peer dem Knoten weit mehr Arbeit aufbürden kann, als er selbst aufwendet; die Analyse markierte den zlib-Codec, Experimente bestätigten den Fehler.
Was das bedeutet
Beide Fehler haben dieselbe Form: Ein nicht authentifizierter Peer schickt eine kleine Eingabe, deren Verarbeitung den Empfänger um Größenordnungen mehr kostet. In einem Peer-to-Peer-Netz, in dem jeder eine Verbindung öffnen kann, ist diese Asymmetrie der ganze Angriff - und ein Lightning-Knoten, der offline geht, kann weder Zahlungen weiterleiten noch rechtzeitig auf Kanalstreitigkeiten reagieren.
Der zweite Fehler erinnert zudem an veraltete Funktionen. Eine Kodierung, die vor vier Jahren aus der Spezifikation gestrichen wurde, war noch akzeptiert, noch erreichbar und noch unbegrenzt. Codepfade, die ein Protokoll nicht mehr braucht, bleiben Angriffsfläche, bis sie gelöscht sind.