#xrpledgerpatchesxrpcreationbug
Wenige Dinge sind für einen Vermögenswert mit festem Angebot wichtiger als das Angebot selbst. Deshalb erregte eine kürzlich offengelegte Schwachstelle im XRP Ledger, durch die nicht autorisierte XRP hätten erstellt werden können, diese Woche Aufmerksamkeit – obwohl der Fehler bereits vor Wochen behoben worden war.
Hier ist der gemeldete Ablauf:
• Der Bericht: Am 22. September meldeten die Forscher Cayden Liao und Veria AI das Problem über das XRPL Bug-Bounty-Programm. RippleX reproduzierte es auf einem eigenständigen Testserver und bestätigte, dass die erstellten XRP ausgegeben werden konnten. • Die Schwachstelle: Ein Integer-Überlauf in der Zahlungs-Engine. Wenn eine einzelne Zahlung genügend Angebote im Orderbuch abwickelte, konnte eine Berechnung auf einen viel kleineren Wert zurückspringen. Dadurch hätten die Verkäufer den vollen Betrag erhalten, während der Käufer deutlich weniger zahlte. Die Differenz hätte aus neu erstellten XRP bestehen können. Der Fehler scheint auf das Jahr 2015 zurückzugehen. • Die Behebung: Version xrpld 3.4.1 wurde am 25. September veröffentlicht und ergänzte Überlaufprüfungen sowie einen größeren Sicherheitszähler. Sie wurde als Notfall-Patch ohne die übliche Abstimmung der Validatoren über eine Änderung veröffentlicht, damit die Schwachstelle nicht während eines öffentlichen Abstimmungszeitraums offengelegt blieb. RippleX zufolge nutzten bis zu diesem Tag mehr als 80 % der standardmäßigen UNL-Validatoren die gepatchte Version oder eine neuere. • Die Offenlegung: Die Einzelheiten wurden am 9. Oktober veröffentlicht. RippleX zufolge gibt es keine Hinweise auf eine Ausnutzung der Schwachstelle. Ein zweiter Fehler mit geringerer Schwere, der die Batch-Funktion betraf, wurde ebenfalls behoben. Zum Zeitpunkt seiner Entdeckung war er im Mainnet nicht aktiv.
Warum das wichtig ist: Ein Fehler bei der Ausgabe neuer Token ist eine andere Kategorie als ein Diebstahlfehler, da er die Integrität des Angebots unmittelbar gefährdet. Um ihn auszunutzen, hätte man eine sorgfältig vorbereitete Konstellation aus Hunderten von Angeboten sowie einigen Hundert XRP als Reserve benötigt. Das könnte erklären, warum der Fehler unentdeckt blieb. Der Vorfall zeigt außerdem zwei Seiten des Prozesses: ein Bug-Bounty-Programm, das wie vorgesehen funktioniert, und den Zielkonflikt zwischen einer schnellen Fehlerbehebung und der dezentralen, abstimmungsbasierten Art, wie das Netzwerk normalerweise verändert wird.
Wenn eine kritische Fehlerbehebung veröffentlicht werden muss, bevor die Community darüber abstimmen kann: Wie sollten Netzwerke Geschwindigkeit, Transparenz und Konsens miteinander in Einklang bringen?
