Das XRP Ledger hat eine kritische Sicherheitslücke behoben, die bis ins Jahr 2015 zurückreicht und es Angreifern ermöglicht hätte, durch eine einzige speziell entworfene Transaktion etwa 18 Billionen XRP zu erzeugen, wobei mehr als 80 % der vertrauenswürdigen Validatoren das Notfall-Update am 25. September installierten.
Zusammenfassung
- XRPL-Entwickler behoben einen kritischen Zahlungsfehler, der ausgabefähige XRP über das Angebot hinaus erzeugen konnte.
- Der Forscher Cayden Liao demonstrierte, dass durch eine einzige konstruierte Transaktion etwa 18 Billionen XRP geprägt werden könnten.
- Das Sicherheitsteam fand keine Hinweise darauf, dass die Überlauf-Schwachstelle in öffentlichen Netzwerken ausgenutzt wurde.
- Mehr als 80 % der Standard-Validatoren aktualisierten am 25. September auf xrpld 3.4.1, bestätigten die Entwickler.
- Eine separate Batch-Validierungskorrektur wurde am 9. Oktober aktiviert, nachdem die Validatoren die ursprünglich geplante Einführung verzögert hatten.
Die XRP Ledger Foundation und RippleX bestätigten die Schwachstelle in einer Offenlegung vom 9. Oktober und erklärten, dass ein Fehler in der Zahlungs-Engine des Netzwerks ausgabefähige XRP über das vorgesehene Angebot von 100 Milliarden hinaus hätte erzeugen können. Entwickler reproduzierten das Problem während Tests und veröffentlichten Version 3.4.1, um es zu beheben. Ihre Untersuchung ergab keine Hinweise darauf, dass die Schwachstelle in einem öffentlichen Netzwerk ausgenutzt wurde. Der Sicherheitsforscher Cayden Liao und Veria AI erhielten die maximale Belohnung des Bug-Bounty-Programms in Höhe von 250.000 US-Dollar, nachdem sie die Schwachstelle gemeldet und ihre potenziellen Auswirkungen demonstriert hatten.
XRP Ledger behebt Fehler, der Billionen XRP hätte erzeugen können
Die Schwachstelle betraf die Zahlungs-Engine des XRP Ledgers, die Überweisungen und Transaktionen im Zusammenhang mit der integrierten dezentralen Börse des Netzwerks verarbeitet.
Laut der offiziellen Offenlegung entstand das Problem durch einen Integer-Überlauf in Software, die 2015 geschrieben wurde. Ein Integer-Überlauf tritt auf, wenn eine Berechnung eine Zahl ergibt, die größer ist, als das Computersystem mit der zugewiesenen Anzahl von Bits darstellen kann.
In diesem Fall addierte die Zahlungs-Engine XRP-Beträge, die mit mehreren Angeboten im Orderbuch des Netzwerks verbunden waren. Die Software verwendete eine 64-Bit-Ganzzahl, um den Gesamtbetrag zu berechnen, den ein Käufer bei Abschluss einer Zahlung mit mehreren Angeboten schuldete.
Entwickler entdeckten, dass ein Angreifer Hunderte von speziell bepreisten Angeboten erstellen und dafür sorgen konnte, dass eine Zahlung sie verbraucht. Wenn der berechnete Gesamtbetrag den Maximalwert der Ganzzahl überschritt, konnte die Zahl auf einen viel kleineren Betrag umschlagen. Das System würde einzelnen Verkäufern dennoch die vollen in ihren Angeboten angegebenen XRP-Beträge gutschreiben, obwohl der Käufer nur den reduzierten Betrag zahlte, der durch den Überlauf entstand. Die Differenz würde XRP erzeugen, das zuvor nicht existierte.
Laut der XRPL Foundation konnte die resultierende Kryptowährung auf andere Konten übertragen, gehandelt oder an Börsen gesendet werden. Der Bericht beschrieb das potenzielle Ergebnis: „Ein Angreifer hätte ausgabefähige XRP weit über das Gesamtangebot hinaus erzeugen können.“
Die Schwachstelle konnte laut Entwicklern nicht durch gewöhnlichen Handel ausgelöst werden. Ein Angreifer hätte mehrere hundert Konten erstellen, ungewöhnlich bepreiste Angebote platzieren und eine sorgfältig konstruierte Transaktion einreichen müssen, um sie zusammen zu verarbeiten. Die bestehenden Sicherheitsprüfungen versagten, weil die Angebotsüberprüfung des Systems dieselbe Art von Arithmetik verwendete, die den ursprünglichen Fehler verursacht hatte.
Unterdessen konnte eine separate Kontostandsprüfung umgangen werden, indem die neu erzeugten XRP auf mehrere Wallets verteilt wurden.
Forscher deckt potenziellen Exploit von 18 Billionen XRP auf
Die Schwachstelle erregte die Aufmerksamkeit der Entwickler, nachdem der Sicherheitsforscher Cayden Liao und Veria AI die Open-Source-Software des XRP Ledgers getestet hatten.
Veria Labs veröffentlichte seine Ergebnisse am 10. Oktober und beschrieb, wie sein automatisiertes Sicherheitstestsystem das Problem am 21. September entdeckte. Am folgenden Tag entwickelten Forscher einen funktionierenden Proof of Concept in einem lokalen Testnetzwerk.
Laut dem Unternehmen zeigte die Demonstration, dass durch eine speziell entworfene Transaktion etwa 18 Billionen XRP erzeugt werden könnten. Der Betrag entsprach nach Berechnung der Forscher ungefähr dem 184-fachen der vorgesehenen Gesamtmenge von XRP. Die Zahl beschreibt die Ergebnisse kontrollierter Sicherheitstests, nicht eine tatsächliche Erhöhung des im Umlauf befindlichen Angebots der Kryptowährung. Liao reichte die Schwachstelle am 22. September über das offizielle XRPL-Bug-Bounty-Programm ein.
RippleX-Ingenieure reproduzierten das Problem auf einem eigenständigen Server und bestätigten, dass die neu erzeugten XRP in einer nachfolgenden Zahlung ausgegeben werden konnten.
Der ursprüngliche Bericht stufte die Schwachstelle als schwerwiegend ein, doch Entwickler erhöhten ihren Schweregrad nach Bestätigung der potenziellen Folgen auf kritisch. Veria Labs erklärte, die Schwachstelle hätte den gesamten Marktwert von XRP gefährden können, wenn Angreifer sie erfolgreich ausgenutzt hätten. Die Schätzung des Unternehmens basierte auf einer damaligen Marktkapitalisierung von XRP von etwa 94 Milliarden US-Dollar.
Die Zahl von 94 Milliarden US-Dollar stellt jedoch die Schätzung des Forschers für das potenzielle finanzielle Risiko dar, nicht bestätigte Verluste. Das Sicherheitsteam fand keine Hinweise auf eine unbefugte Erzeugung von XRP in öffentlichen Netzwerken. Am 8. Oktober erhielt Veria AI die maximale Prämie von 250.000 US-Dollar für die Identifizierung und verantwortungsvolle Offenlegung des Problems.
RippleX veröffentlicht Notfall-Fix ohne normalen Genehmigungsprozess
Nach Bestätigung der Schwachstelle entwickelten RippleX-Ingenieure zwischen dem 22. und 23. September einen Fix. Der Patch wurde in xrpld Version 3.4.1 aufgenommen, die am 25. September veröffentlicht wurde.
Laut der offiziellen Offenlegung fügten Entwickler Prüfungen hinzu, die verhindern, dass die Zahlungs-Engine Berechnungen akzeptiert, die den zulässigen Ganzzahlbereich überschreiten. Die aktualisierte Software lehnt betroffene Berechnungen ab und gibt stattdessen einen gewöhnlichen Zahlungsfehler zurück, anstatt zusätzliche XRP zu erzeugen. Ingenieure verstärkten die Angebotsverifizierung des Netzwerks, indem sie die bestehende Arithmetik durch einen breiteren Zähler ersetzten, der ähnliche Fehler erkennen soll. Zusätzliche Saldenberechnungen wurden vorsorglich überprüft.
Die Entscheidung, den Fix einzusetzen, führte jedoch zu einer ungewöhnlichen Situation für die Governance des XRP Ledger. Normalerweise müssen Änderungen an der Transaktionsverarbeitung das Amendment-System des Netzwerks durchlaufen. Ein Amendment erfordert die Unterstützung von mehr als 80 % der vertrauenswürdigen Validatoren über zwei aufeinanderfolgende Wochen vor der Aktivierung.
Für die Zahlungsüberlauf-Schwachstelle entschieden sich Entwickler, den Fix sofort anzuwenden, wenn Validatoren ihre Software aktualisierten. Die XRPL Foundation erklärte, dass der normale Prozess die Schwachstelle offengelegt hätte, während sie während des Genehmigungszeitraums ausnutzbar geblieben wäre.
Da die XRP-Ledger-Software Open Source ist, kann die Veröffentlichung eines Patches den Ort und die Art einer Schwachstelle offenbaren.
Entwickler kamen zu dem Schluss, dass das Warten auf den üblichen Amendment-Prozess zusätzliche Sicherheitsrisiken hätte schaffen können. Der Notfallansatz barg eine separate Sorge: Validatoren, die unterschiedliche Softwareversionen ausführen, könnten sich darüber uneinig sein, wie eine bösartige Transaktion zu verarbeiten ist.
In einem extremen Szenario könnte die Uneinigkeit das Netzwerk vorübergehend daran hindern, neue Ledger zu bestätigen. Die Foundation sagte, die Entscheidung sei in Absprache mit RippleX, Validator-Betreibern und anderen XRPL-Mitwirkenden getroffen worden. Bis zum 25. September hatten mehr als 80 % der Validatoren auf der standardmäßigen Unique Node List auf Version 3.4.1 aktualisiert.
Der öffentliche Quellcode wurde anschließend nach der sofortigen Sicherheitsreaktion veröffentlicht. Die Release-Aufzeichnungen der XRPL Foundation beschreiben Version 3.4.1 als ein Notfall-Update, das sicherheitssensible Protokollprobleme adressiert.
XRP Ledger behebt zweiten Sicherheitsfehler vor Batch-Aktivierung
Die Offenlegung vom 9. Oktober betraf eine weitere Schwachstelle im Zusammenhang mit der Batch-Transaktionsfunktion des XRP Ledger. Batch ermöglicht es Entwicklern, bis zu acht Transaktionen zu einem Vorgang zusammenzufassen. Die Funktion unterstützt verschiedene Ausführungsmodi, darunter Arrangements, bei denen jede Transaktion erfolgreich sein muss, damit der gesamte Vorgang akzeptiert wird.
Während Sicherheitstests entdeckten Forscher einen Validierungsfehler bezüglich der Art und Weise, wie einzelne Transaktionen innerhalb eines Batch verpackt wurden. Das Protokoll erforderte, dass jede Transaktion ein bestimmtes Feld namens RawTransaction verwendet.
Allerdings könnte die Software unter bestimmten Bedingungen alternative Feldnamen akzeptieren. Ermittler fanden heraus, dass verschiedene Serverversionen diese falsch formatierten Transaktionen unterschiedlich verarbeiten könnten.
Laut der XRPL Foundation könnte die daraus resultierende Uneinigkeit die Netzwerkvalidierung unterbrechen, wenn die Funktion aktiviert würde, bevor das Problem behoben wäre. Das Problem wurde ursprünglich während des Sherlock Attackathon identifiziert und später von dem XRPL Foundation-Mitwirkenden Denis Angell untersucht. Der RippleX-Ingenieur Mayukha Vadari stellte fest, dass die Schwachstelle ein potenzielles Konsensrisiko zwischen Serverversionen darstellte.
Die Entwickler reagierten mit der Einführung der Änderung fixBatchV1_2. Die Änderung verlangt, dass jede Batch-Transaktion das genehmigte Feldformat verwendet, und lehnt falsch verpackte Transaktionen ab. Die Validatoren zogen vorübergehend ihre Unterstützung für den früheren Aktivierungsplan BatchV1_1 zurück, während die Entwickler die Korrektur abschlossen.
Sowohl fixBatchV1_2 als auch BatchV1_1 wurden am 9. Oktober im XRP Ledger Mainnet aktiviert. Die XRP Ledger Batch-Aktivierung erhielt Unterstützung von 30 Validatoren, wobei fünf das Upgrade ablehnten, so die XRPScan-Zahlen, die im verifizierten Netzwerkbericht enthalten sind.
Frühere Untersuchungen zur Batch-Sicherheitsüberprüfung beschrieben die Notveröffentlichung vom 25. September und die erforderlichen Schutzmaßnahmen, bevor die Funktion aktiviert werden konnte. Die ursprüngliche Version war zuvor mit Sicherheitsbedenken konfrontiert, einschließlich Problemen mit der Transaktionsautorisierung, die während Entwicklerüberprüfungen aufgedeckt wurden.
Ein separates XRP Ledger-Sicherheitsaudit im August dokumentierte 96 gültige Schwachstellen, die während eines Sherlock-Wettbewerbs identifiziert wurden, der vorgeschlagene Protokollfunktionen abdeckte.
Für die neueste Batch-Schwachstelle bestätigte die XRPL Foundation, dass die betroffenen Änderungen zum Zeitpunkt der Entdeckung des Problems nicht im Mainnet aktiv waren. Es gingen keine Nutzergelder verloren, keine privaten Schlüssel wurden kompromittiert und es trat kein Konsensfehler aufgrund dieses speziellen Fehlers auf. Die Aktivierung am 9. Oktober bedeutet, dass Server, die ältere Softwareversionen ausführen, jetzt durch die Änderung blockiert sind und auf Version 3.4.1 oder höher aktualisieren müssen, um synchronisiert zu bleiben.
Die XRPL Foundation erklärte, dass sie eine zusätzliche Überprüfungsanforderung für zukünftige Softwareveröffentlichungen einführen wird: Zuvor gemeldete Sicherheitsprobleme müssen erneut gegen Release-Kandidaten getestet werden, bevor sie als behoben eingestuft werden.
Laut der Stiftung wird das Verfahren auf Ergebnisse aus Audits, Bug-Bounty-Programmen, KI-gestützten Sicherheitstests und anderen Schwachstellenbewertungen angewendet.
