Die Ausnutzung des Lightning Bug war die ethische Entscheidung

Dies ist ein Meinungsleitartikel von Shinobi, einem autodidaktischen Pädagogen im Bitcoin-Bereich und technisch orientierten Bitcoin-Podcast-Moderator.

Zum zweiten Mal in etwa einem Monat wurde bei btcd/LND ein Fehler ausgenutzt, der dazu führte, dass sie im Konsens von Bitcoin Core abwichen. Wieder einmal war Burak der Entwickler, der diese Schwachstelle ausgelöst hat – dieses Mal war es eindeutig beabsichtigt – und wieder einmal handelte es sich um ein Problem mit dem Code zum Parsen von Bitcoin-Transaktionen oberhalb der Konsensschicht. Wie ich in meinem besprochen habe Stück zum vorherigen Fehler Dass Burak ausgelöst wurde, gab es vor Taproot Beschränkungen hinsichtlich der Größe der Skript- und Zeugendaten in einer Transaktion. Mit der Aktivierung von Taproot wurden diese Beschränkungen entfernt, so dass nur noch die Beschränkungen der Blockgrößenbeschränkung selbst übrig blieben, um diese Teile einzelner Transaktionen zu begrenzen. Das Problem mit dem letzten Fehler bestand darin, dass trotz der Tatsache, dass der Konsenscode in btcd ordnungsgemäß aktualisiert wurde, um diese Änderung widerzuspiegeln, der Code für die Peer-to-Peer-Übertragung – einschließlich der Analyse von Daten vor dem Senden oder Empfangen – nicht ordnungsgemäß aktualisiert wurde. Der Code, der Blöcke und Transaktionen verarbeitete, bevor er tatsächlich zur Konsensvalidierung weitergeleitet wurde, scheiterte an den Daten, übergab sie nie an die Konsensvalidierungslogik und der betreffende Block konnte nie validiert werden.

Diesmal geschah etwas ganz Ähnliches. Eine weitere Einschränkung im Peer-to-Peer-Abschnitt der Codebasis bestand darin, dass fälschlicherweise eine Beschränkung der Zeugendaten erzwungen wurde, die diese auf maximal 1/8 der Blockgröße im Gegensatz zur vollen Blockgröße beschränkte. Burak fertigte ein Transaktion mit Zeugendaten, die nur eine einzige Gewichtseinheit über dem strengen Grenzwert lagen, und btcd- und LND-Knoten erneut auf dieser Blockhöhe blockiert. Bei dieser Transaktion handelte es sich um eine nicht standardmäßige Transaktion. Das bedeutet, dass sie zwar gemäß den Konsensregeln vollkommen gültig ist, gemäß der Standard-Mempool-Richtlinie jedoch nicht gültig ist und Knoten sie daher nicht über das Netzwerk weiterleiten. Es ist durchaus möglich, es in einen Block zu schürfen, aber die einzige Möglichkeit, dies zu tun, besteht darin, es direkt einem Miner zur Verfügung zu stellen, was Burak mit Hilfe von F2Pool getan hat.

Dies macht deutlich, dass jeder Code, dessen Zweck darin besteht, Bitcoin-Daten zu analysieren und zu validieren, einer umfassenden Prüfung unterzogen werden muss, um sicherzustellen, dass er mit der Funktionsweise von Bitcoin Core übereinstimmt. Es spielt keine Rolle, ob es sich bei diesem Code um die Konsens-Engine für eine Knotenimplementierung oder nur um einen Code handelt, der Transaktionen für einen Lightning-Knoten weiterleitet. Dieser zweite Fehler war buchstäblich direkt über dem vom letzten Monat in der Codebasis. Es wurde nicht einmal von irgendjemandem bei Lightning Labs entdeckt. AJ Towns meldete es am 11. Oktober, zwei Tage nachdem der ursprüngliche Fehler durch Buraks 998-von-999-Multisig-Transaktion ausgelöst wurde. Es wurde 10 Stunden lang öffentlich auf Github gepostet, bevor es gelöscht wurde. Anschließend wurde ein Fix vorgenommen, aber nicht veröffentlicht, mit der Absicht, das Problem in der nächsten Version von LND stillschweigend zu beheben.

Dies ist ein ziemlich normales Verfahren für eine schwerwiegende Sicherheitslücke, insbesondere bei einem Projekt wie Bitcoin Core, bei dem eine solche Sicherheitslücke tatsächlich ernsthaften Schaden am Basisschichtnetzwerk/-protokoll anrichten kann. Aber in diesem speziellen Fall stellte es ein ernstes Risiko für die Gelder der LND-Benutzer dar, und angesichts der Tatsache, dass es sich buchstäblich direkt neben dem vorherigen Fehler befand, der die gleichen Risiken mit sich brachte, waren die Chancen, dass er gefunden und ausgenutzt wurde, sehr hoch. wie von Burak demonstriert. Dies wirft die Frage auf, ob der Quiet-Patch-Ansatz der richtige Weg ist, wenn es um Schwachstellen wie diese geht, die Benutzer dem Diebstahl von Geldern aussetzen können (weil ihr Knoten nicht mehr in der Lage ist, alte Kanalzustände zu erkennen und sie angemessen zu bestrafen).

Wie ich in meinem Artikel über den letzten Fehler dargelegt habe, hätte ein böswilliger Akteur, wenn er die Fehler vor einem wohlmeinenden Entwickler gefunden hätte, taktisch neue Kanäle zu anfälligen Knoten geöffnet, den gesamten Inhalt dieser Kanäle an sich selbst zurückgeleitet und dann habe den Fehler ausgenutzt. Von da an hätten sie diese Gelder unter ihrer Kontrolle und könnten auch den Kanal mit dem Ausgangszustand schließen, was ihr Geld buchstäblich verdoppelt. Was Burak tat, indem er dieses Problem auf ironische Weise aktiv ausnutzte, schützte LND-Benutzer tatsächlich vor einem solchen Angriff.

Sobald es ausgenutzt wurde, waren die Benutzer anfällig für solche Angriffe von bereits existierenden Kollegen, mit denen sie bereits offene Kanäle hatten, aber sie waren nicht mehr in der Lage, mit neuen Kanälen gezielt angegriffen zu werden. Ihre Knoten waren blockiert und konnten Zahlungen über Kanäle, die jemand zu öffnen versuchte, nach der Blockierung, die ihren Knoten blockierte, nie erkennen oder verarbeiten. Das Risiko, dass Benutzer ausgenutzt werden, wurde dadurch zwar nicht vollständig beseitigt, das Risiko wurde jedoch auf Personen beschränkt, mit denen sie bereits einen Kanal hatten. Buraks Vorgehen hat es gemildert. Persönlich denke ich, dass diese Art von Aktion als Reaktion auf den Fehler sinnvoll war; Es begrenzte den Schaden, machte die Benutzer auf das Risiko aufmerksam und führte zu einer schnellen Fehlerbehebung.

LND war auch nicht das Einzige, was betroffen war. Flüssigkeit Der Pegging-Prozess war ebenfalls unterbrochen, was Aktualisierungen der Funktionäre des Verbandes erfordert, um das Problem zu beheben. Ältere Versionen von Rust Bitcoin waren ebenfalls betroffen, was dazu führte, dass der Stillstand einige Block-Explorer und Electrs-Instanzen (eine Implementierung des Backend-Servers für Electrum Wallet) betraf. Mit Ausnahme der Tatsache, dass Liquids Bindung die Gelder schließlich nach Ablauf einer Zeitsperre an die von Blockstream gehaltenen Notfall-Wiederherstellungsschlüssel weitergibt – und realistischerweise weiß in der Raubüberfall-ähnlichen Filmhandlung, in der Blockstream diese Gelder gestohlen hat, jeder genau, wen er angreifen muss – diese anderen Probleme gefährden zu keinem Zeitpunkt die Gelder von irgendjemandem. Außerdem hatte Rust Bitcoin diesen spezifischen Fehler tatsächlich in neueren Versionen behoben, was offenbar nicht zu einer Kommunikation mit Betreuern anderer Codebasen führte, um das Potenzial für solche Probleme hervorzuheben. Erst durch die aktive Ausnutzung des Fehlers live im Netzwerk wurde deutlich, dass das Problem in mehreren Codebasen bestand.

Dies wirft einige große Probleme auf, wenn es um Schwachstellen wie diese in Layer-2-Software auf Bitcoin geht. Erstens die Ernsthaftigkeit, mit der diese Codebasen auf Sicherheitslücken überprüft werden, und die Priorisierung dieser gegenüber der Integration neuer Funktionen. Ich denke, es ist sehr aufschlussreich, dass Sicherheit nicht immer Priorität hat, wenn man bedenkt, dass dieser zweite Fehler von den Betreuern der Codebasis, in der er vorhanden war, nicht einmal gefunden wurde, obwohl er buchstäblich direkt neben dem ersten Fehler lag, der letzten Monat entdeckt wurde. Wurde nach einem großen Fehler, der die Gelder der Benutzer gefährdete, keine interne Prüfung dieser Codebasis durchgeführt? Es brauchte jemanden von außerhalb des Projekts, um es zu entdecken? Dies zeigt nicht, dass der Schutz der Benutzergelder Vorrang vor der Entwicklung neuer Funktionen hat, um mehr Benutzer anzulocken. Zweitens zeigt die Tatsache, dass dieses Problem bereits in Rust Bitcoin behoben wurde, einen Mangel an Kommunikation zwischen Betreuern verschiedener Codebasen in Bezug auf Fehler wie diesen. Das ist durchaus verständlich, denn völlig unterschiedliche Codebasen lassen jemanden, der einen Fehler darin entdeckt, nicht sofort denken: „Ich sollte andere Teams kontaktieren, die ähnliche Software in völlig anderen Programmiersprachen schreiben, um sie vor der Möglichkeit eines solchen Fehlers zu warnen.“ Sie finden keinen Fehler in Windows und denken dann sofort daran, den Fehler den Linux-Kernel-Betreuern zu melden. Bitcoin als Protokoll für verteilten Konsens über ein globales Netzwerk ist jedoch eine ganz andere Sache; Vielleicht sollten Bitcoin-Entwickler anfangen, in diese Richtung zu denken, wenn es um Schwachstellen in Bitcoin-Software geht. Insbesondere wenn es um das Parsen und Interpretieren von konsensbezogenen Daten geht.

Wenn es schließlich um Protokolle wie Lightning geht, die darauf angewiesen sind, die Blockchain jederzeit zu beobachten, um auf alte Kanalzustände reagieren zu können, um die Sicherheit aufrechtzuerhalten, sollte das unabhängige Parsen und Überprüfen von Daten auf ein absolutes Minimum beschränkt werden – wenn … nicht vollständig entfernt und an Bitcoin Core oder direkt daraus abgeleitete Daten delegiert. Core Lightning ist auf diese Weise aufgebaut, stellt eine Verbindung zu einer Instanz von Bitcoin Core her und ist bei der Validierung von Blöcken und Transaktionen vollständig von dieser abhängig. Wenn LND auf die gleiche Weise funktionieren würde, hätte keiner dieser Fehler in BTCD LND-Benutzer in einer Weise beeinträchtigt, die ihre Gelder gefährdet hätte.

Unabhängig davon, wie die Dinge gehandhabt werden – entweder die Validierung vollständig auslagern oder einfach die interne Validierung minimieren und mit viel größerer Sorgfalt angehen – zeigt dieser Vorfall, dass sich bei der Herangehensweise an die Frage, wie Layer-2-Software mit der Interaktion mit konsensbezogenen Daten umgeht, etwas ändern muss. Wieder einmal ist es für alle ein großes Glück, dass dies nicht von einem böswilligen Akteur ausgenutzt wurde, sondern von einem Entwickler, der seine Sache bewiesen hat. Allerdings kann Bitcoin nicht damit rechnen, Glück zu haben oder darauf zu hoffen, dass es keine böswilligen Akteure gibt.

Entwickler und Benutzer sollten sich darauf konzentrieren, die Prozesse zu verbessern, um zu verhindern, dass sich Vorfälle wie dieser wiederholen, und nicht das Spiel der Schuldzuweisungen wie eine heiße Kartoffel spielen.

Dies ist ein Gastbeitrag von Shinobi. Die geäußerten Meinungen sind ausschließlich ihre eigenen und spiegeln nicht unbedingt die von BTC Inc oder Bitcoin Magazine wider.