Exploiting The Lightning Bug Was Ethical – Bitcoin Magazine

Exploiting The Lightning Bug Was Ethical – Bitcoin Magazine

Dies ist eine redaktionelle Meinung von Shinobi, einem autodidaktischen Pädagogen im Bitcoin-Bereich und technisch orientierten Bitcoin-Podcast-Host.

Zum zweiten Mal in ungefähr 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 – diesmal war es eindeutig beabsichtigt – und wieder einmal war es ein Problem mit Code zum Analysieren von Bitcoin-Transaktionen über der Konsensschicht. Wie ich in meinem Artikel über den früheren Fehler besprochen habe, den Burak ausgelöst hat, gab es vor Taproot Grenzen dafür, wie groß die Skript- und Zeugendaten in einer Transaktion sein konnten. Mit der Aktivierung von Taproot wurden diese Limits 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 war, dass trotz der Tatsache, dass der Konsenscode in btcd ordnungsgemäß aktualisiert wurde, um diese Änderung widerzuspiegeln, der Code, der die Peer-to-Peer-Übertragung handhabt – einschließlich des Analysierens von Daten vor dem Senden oder Empfangen – nicht ordnungsgemäß aktualisiert wurde. Die Code-Verarbeitungsblöcke und -transaktionen, bevor sie tatsächlich zur Validierung für den Konsens übergeben wurden, haben die Daten nicht bestanden, sie nie an die Konsens-Validierungslogik weitergegeben, und der fragliche Block wurde nie validiert.

Diesmal geschah etwas ganz Ähnliches. Ein weiteres Limit im Peer-to-Peer-Abschnitt der Codebasis bestand darin, eine Einschränkung der Zeugendaten falsch durchzusetzen und sie auf maximal 1/8 der Blockgröße im Gegensatz zur vollen Blockgröße zu beschränken. Burak erstellte eine Transaktion mit Zeugendaten, die nur eine Gewichtseinheit über der strengen Grenze lag, und brachte erneut BTCD- und LND-Knoten bei dieser Blockhöhe zum Stillstand. Diese Transaktion war eine Nicht-Standard-Transaktion, was bedeutet, dass sie, obwohl sie nach Konsensregeln vollkommen gültig ist, gemäß der Standard-Mempool-Richtlinie nicht gültig ist und daher von den Knoten nicht über das Netzwerk weitergeleitet wird. Es ist durchaus möglich, es in einen Block abzubauen, aber der einzige Weg, dies zu tun, besteht darin, es direkt einem Miner zur Verfügung zu stellen, was Burak mit Hilfe von F2Pool getan hat.

Dies verdeutlicht wirklich, dass jeder Codeabschnitt, dessen Zweck darin besteht, Bitcoin-Daten zu analysieren und zu validieren, streng geprüft werden muss, um sicherzustellen, dass er mit dem übereinstimmt, was Bitcoin Core tun wird. Es spielt keine Rolle, ob dieser Code die Konsens-Engine für eine Node-Implementierung oder nur ein Stück Code ist, der Transaktionen für einen Lightning-Node weiterleitet. Dieser zweite Fehler war in der Codebasis buchstäblich direkt über dem vom letzten Monat. Es wurde nicht einmal von irgendjemandem bei Lightning Labs entdeckt. AJ Towns meldete dies 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. Daraufhin wurde eine Lösung vorgenommen, aber nicht veröffentlicht, mit der Absicht, das Problem in der nächsten Version von LND stillschweigend zu beheben.

Nun, dies ist ein ziemlich übliches Verfahren für eine ernsthafte Schwachstelle, insbesondere bei einem Projekt wie Bitcoin Core, wo eine solche Schwachstelle tatsächlich ernsthafte Schäden am Basisschicht-Netzwerk/Protokoll verursachen kann. Aber in diesem speziellen Fall stellte es ein ernsthaftes 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 hatte, waren die Chancen, dass es 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 in der Lage ist, alte Kanalzustände zu erkennen und sie angemessen zu bestrafen).

Wie ich in meinem Artikel über den letzten Fehler einging, 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 öffnen, den gesamten Inhalt dieser Kanäle zu sich selbst zurückleiten und dann ausnutzen können der Käfer. Von dort aus hätten sie diese Gelder unter ihrer Kontrolle und könnten auch den Kanal mit dem ursprünglichen Zustand schließen und ihr Geld buchstäblich verdoppeln. 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 Benutzer solchen Angriffen von bereits bestehenden Peers ausgesetzt, mit denen sie bereits offene Kanäle hatten, aber sie waren nicht mehr in der Lage, gezielt mit neuen Kanälen angegriffen zu werden. Ihre Knoten waren blockiert und würden niemals Zahlungen über Kanäle erkennen oder verarbeiten, die jemand zu öffnen versuchte, nachdem die Blockierung ihren Knoten blockiert hatte. Obwohl es das Risiko der Ausbeutung von Benutzern nicht vollständig beseitigte, begrenzte es dieses Risiko auf Personen, mit denen sie bereits einen Kanal hatten. Buraks Aktion milderte es. Ich persönlich denke, 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 dazu, dass es schnell gepatcht wurde.

LND war auch nicht das Einzige, was betroffen war. Der Pegging-Prozess von Liquid war ebenfalls fehlerhaft, sodass Updates für die Funktionäre des Verbands erforderlich waren, um ihn zu beheben. Ältere Versionen von Rust Bitcoin waren ebenfalls betroffen, was dazu führte, dass der Stall einige Block-Explorer und Electrs-Instanzen (eine Implementierung des Backend-Servers für Electrum Wallet) beeinträchtigte. Jetzt, mit Ausnahme von Liquids Peg, der schließlich Gelder den von Blockstream gehaltenen Notfallwiederherstellungsschlüsseln nach Ablauf einer Zeitsperre aussetzt – und realistischerweise in der Filmhandlung im Überfallstil, in der Blockstream diese Gelder gestohlen hat, weiß jeder genau, wen er verfolgen muss – diese anderen Probleme gefährdeten zu keinem Zeitpunkt die Gelder von irgendjemandem. Außerdem hatte Rust Bitcoin diesen spezifischen Fehler tatsächlich in neueren Versionen gepatcht, was anscheinend zu keiner Kommunikation mit Betreuern anderer Codebasen führte, um das Potenzial für solche Probleme hervorzuheben. Es war nur die aktive Ausnutzung des Fehlers live im Netzwerk, die weithin aufgedeckt hat, dass das Problem in mehreren Codebasen existierte.

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 Sicherheitsfehler geprüft werden und wie dies gegenüber der Integration neuer Funktionen priorisiert wird. Ich denke, es ist sehr aufschlussreich, dass Sicherheit nicht immer priorisiert wird, da dieser zweite Fehler nicht einmal von den Betreuern der Codebasis gefunden wurde, in der er vorhanden war, 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 anzuziehen. Zweitens zeigt die Tatsache, dass dieses Problem bereits in Rust Bitcoin gepatcht wurde, einen Mangel an Kommunikation zwischen den Betreuern verschiedener Codebasen in Bezug auf solche Fehler. Das ist ziemlich verständlich, da jemand, der einen Fehler in einer Codebasis gefunden hat, nicht sofort denkt, wenn er völlig unterschiedliche Codebasen hat: „Ich sollte mich an andere Teams wenden, 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 Betreuern des Linux-Kernels zu melden. Bitcoin als Protokoll für verteilten Konsens über ein globales Netzwerk ist jedoch ein ganz anderes Tier; Vielleicht sollten Bitcoin-Entwickler anfangen, in diese Richtung zu denken, wenn es um Schwachstellen in Bitcoin-Software geht. Vor allem, wenn es um das Parsen und Interpretieren von konsensbezogenen Daten geht.

Schließlich sollte vielleicht bei Protokollen wie Lightning, die darauf angewiesen sind, die Blockchain jederzeit zu beobachten, um auf alte Kanalzustände reagieren zu können, um die Sicherheit aufrechtzuerhalten, das unabhängige Parsen und Verifizieren von Daten auf ein absolutes Minimum beschränkt werden – falls nicht vollständig entfernt und an Bitcoin Core delegiert oder direkt daraus abgeleitete Daten. Core Lightning ist auf diese Weise aufgebaut, stellt eine Verbindung zu einer Instanz von Bitcoin Core her und ist für die Validierung von Blöcken und Transaktionen vollständig davon abhängig. Wenn LND auf die gleiche Weise funktioniert hätte, hätte keiner dieser Fehler in btcd die LND-Benutzer in einer Weise beeinträchtigt, die ihre Gelder gefährdet hätte.

Wie auch immer die Dinge gehandhabt werden – entweder die Validierung vollständig auslagern oder einfach die interne Validierung minimieren und mit viel mehr Sorgfalt angehen – dieser Vorfall zeigt, dass sich etwas ändern muss, wenn es darum geht, wie Layer-2-Software mit der Interaktion mit konsensbezogenen Daten umgeht. Wieder einmal haben alle großes Glück, dass dies nicht von einem böswilligen Akteur ausgenutzt wurde, sondern von einem Entwickler, der einen Punkt beweist. Davon abgesehen kann Bitcoin nicht darauf zählen, Glück zu haben oder zu hoffen, dass böswillige Akteure nicht existieren.

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 spielen, Schuldzuweisungen wie eine heiße Kartoffel herumzuwerfen.

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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert