Das Entwicklungsteam des XRP Ledger (XRPL) offenbarte am 9. Oktober eine Integer-Overflow-Schwachstelle, die unter sorgfältig konstruierten Bedingungen hätte ermöglichen können, spendierbares XRP aus dem Nichts zu erschaffen. Der Fix wurde am 25. September in xrpld Version 3.4.1 ausgeliefert, rund zwei Wochen vor der öffentlichen Offenlegung, und das Team berichtete, keine Hinweise darauf gefunden zu haben, dass die Schwachstelle jemals in einem öffentlichen Netzwerk ausgenutzt wurde.

Die Details wurden in XRPLs Vulnerability-Disclosure-Bericht vom 9. Oktober dargelegt.

Eine Zahlungsberechnung, die XRP aus dem Nichts hätte erzeugen können

Der Bericht beschreibt eine Integer-Overflow-Schwachstelle in der Payment-Engine des Ledgers. Unter sorgfältig konstruierten Bedingungen hätte eine Zahlung, die viele Orderbuch-Angebote verbrauchte, Konten mit XRP gutschreiben können, das der Sender tatsächlich nie bezahlt hatte. Orderbücher sind eine native XRPL-Struktur, Teil der integrierten Börse des Ledgers, sodass sich die fehlerhafte Arithmetik in Code befindet, der dem Handel auf dem Ledger ebenso zugrunde liegt wie Zahlungen.

Jedes einzelne Angebot in der Transaktion konnte für sich genommen gültig erscheinen. Der Fehler trat auf, wenn die Engine die XRP-Beträge über alle hinweg addierte. Sobald die Summe die maximale Größe der für diese Berechnung verwendeten Zahl überschritt, konnte sie auf einen viel kleineren Wert überlaufen, anstatt einen Fehler zu erzeugen.

In diesem Szenario hätte die Engine den Angebotseigentümern weiterhin ihre vollen XRP-Beträge gutgeschrieben, während vom Käufer nur der überlaufene Gesamtbetrag abgebucht wurde. Die Differenz stellte neu erschaffenes XRP dar, das anschließend wie jeder andere Kontostand bewegt, gehandelt oder an eine Börse gesendet werden konnte.

Warum die Schwachstelle ernst war

Der Angriff erforderte kein großes XRP-Guthaben. Ein Angreifer hätte die Konten kontrollieren können, die die Angebote platzierten, die erforderlichen Kontoreserven und Transaktionsgebühren bezahlen und dann das erschaffene XRP auf diese Konten verteilen können.

Die Schwachstelle betraf die Zahlungsarithmetik und nicht den Wallet-Zugriff, sodass Kontoschlüssel unberührt blieben. Zu ihrer Auslösung waren Hunderte gezielt bepreiste Angebote und eine Transaktion erforderlich, die darauf ausgelegt war, sie gemeinsam zu verbrauchen; eine gewöhnliche XRP-Zahlung oder ein gewöhnlicher Handel würde die für den Überlauf erforderlichen Werte nicht annähernd erreichen.

Für ein Ledger gibt es kaum empfindlichere Defekte als einen, der spendierbare Einheiten erzeugen kann, denn Kontostand hängt davon ab, dass neues XRP nur über die definierten Regeln des Netzwerks in Umlauf gelangt.

XRPL teilte mit, keine Hinweise auf eine Ausnutzung in einem öffentlichen Netzwerk gefunden zu haben, und es wurden keine Kompromittierung privater Schlüssel, kein Verlust von Guthaben und kein Konsensfehler gemeldet. Die Schwachstelle war offenbar vorhanden, seit die aktuelle Payment-Engine 2015 geschrieben wurde, und blieb unentdeckt, weil normale Aktivitäten das arithmetische Limit nie erreichten.

Der bestehende Schutz des Ledgers gegen neu erschaffenes XRP stützte sich ebenfalls auf dieselbe Art der Addition. Er konnte auf die gleiche Weise überlaufen wie die Payment-Engine, sodass die Transaktion normal erschien, anstatt den unerwarteten Anstieg der Guthaben zu kennzeichnen.

Warum die Entwickler einen Notfalleinsatz wählten

Die Entwickler veröffentlichten den Overflow-Fix, bevor sie seine technischen Details veröffentlichten, da ein normaler Amendment-Zeitplan einen bekannten Exploit über Wochen hinweg verfügbar gelassen hätte. Der Patch wurde am 25. September in xrpld Version 3.4.1 ausgeliefert, die öffentliche Offenlegung folgte am 9. Oktober.

XRPL ändert Transaktionsregeln normalerweise durch Amendments. Validatoren aktualisieren zunächst ihre Software und unterstützen diese dann für einen festgelegten Zeitraum, bevor die neue Regel an demselben Ledger-Punkt im gesamten Netzwerk aktiviert wird. Dieser Prozess vermeidet Situationen, in denen verschiedene Server zu unterschiedlichen Schlussfolgerungen über dieselbe Transaktion gelangen.

Das Abwarten dieses Prozesses hätte in diesem Fall ein schwieriges Problem geschaffen. Da xrpld Open Source ist, hätte die Veröffentlichung der Reparatur Angreifern zeigen können, wo sie suchen müssen, während ältere Software weiterhin den verwundbaren Transaktionspfad akzeptierte. Das Team ließ die neue Overflow-Prüfung daher wirksam werden, sobald ein einzelnes Server-Upgrade durchgeführt wurde.

Dieser schnellere Ansatz brachte ein vorübergehendes Kompatibilitätsrisiko mit sich: Ein ungepatchter Server hätte eine Exploit-Transaktion akzeptieren können, die ein aktualisierter Server ablehnte. Die Entwickler hielten dies für weniger gefährlich, als zuzulassen, dass erschaffenes XRP auf den Markt gelangt. Dem Bericht zufolge hatten mehr als 80 % der Validatoren auf der Standard-UNL am Tag der Veröffentlichung von Version 3.4.1 das Upgrade durchgeführt.

Die Offenlegung umfasste einen zweiten, separaten Fehler

Der Bericht beschrieb außerdem ein Validierungsproblem in XRPLs bevorstehender Batch-Funktion, mit der Nutzer mehrere Transaktionen als eine Einheit einreichen können. Der Fehler könnte dazu geführt haben, dass Server mit unterschiedlichen Softwareversionen bei einer fehlerhaften Batch-Transaktion zu unterschiedlichen Ergebnissen kommen, was die Ledger-Validierung unterbricht oder Anwendungen beschädigt, die Transaktionsdaten parsen.

Der Batch-Fehler wurde entdeckt, bevor die Funktion das Mainnet erreichte. Das Overflow-Problem betraf hingegen bestehenden Payment-Engine-Code, weshalb sein Patch nicht auf einen Standard-Aktivierungszyklus warten konnte. Da die Funktion selbst noch aussteht, ist ihre Ankunft im Mainnet mit bereits vorhandenem Validierungsfix der Teil dieser Offenlegung, der noch bevorsteht.

Der Bericht erschien, während XRPL auchneue Kontokontroll-Tools für Unternehmen aktivierte](https://coindoo.com/xrp-ledger-gives-banks-new-wallet-controls/). Die Änderungen betreffen unterschiedliche Teile des Ledgers, doch beide hängen davon ab, dass Node-Betreiber, Wallet-Anbieter und Entwickler denselben aktuellen Regeln folgen.

Was Nutzer und Betreiber tun müssen

Reguläre XRP-Inhaber müssen keine Gelder bewegen, keine Wallet ersetzen oder ihre Token tauschen. Das Update betrifft die Software, die Transaktionen validiert, und nicht Kontostände, Wallet-Schlüssel oder das von Nutzern gehaltene XRP-Angebot.

• XRP-Inhaber: Keine Maßnahmen erforderlich.
• Börsennutzer: Beachten Sie Plattformhinweise, falls eine Börse Wartungsarbeiten an ihrer eigenen XRPL-Infrastruktur durchführt.
• Node-Betreiber: Führen Sie ein Upgrade auf xrpld 3.4.1 oder höher durch, um mit dem Netzwerk synchron zu bleiben. Ältere Server sind nach der Aktivierung des Batch-Fixes nun amendment-blockiert, d. h. sie können den aktuellen Ledger-Regeln nicht weiter folgen, bis sie ein Update durchführen.

Der Fix schützte XRP-Angebotsregeln, bevor sie auf die Probe gestellt wurden

Die Offenlegung zeigt, wie nahe das Ledger einer Verletzung der Angebotsintegrität war und warum die Validatoren schnell handelten. Der Fehler wurde behoben, bevor seine Details öffentlich wurden, kein Exploit wurde gefunden, und die Payment-Engine verwendet nun Prüfungen, die dieselbe Klasse arithmetischer Fehler stoppen sollen, bevor sie ein validiertes Ledger erreicht. Von außen bleibt abzuwarten, wie schnell sich der Rest des Netzwerks auf xrpld 3.4.1 oder höher konvergiert, da ungepatchte Server bereits amendment-blockiert sind und dem aktuellen Ledger nicht folgen können.

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Anlage- oder technischen Beratung dar. Node-Betreiber sollten die aktuellen XRPL-Release-Dokumentationen konsultieren, bevor sie Produktionsinfrastrukturen aktualisieren.

Dieser Artikel basiert auf einer Berichterstattung, die ursprünglich von Coindoo veröffentlicht wurde.