Ripple Director of Engineering Vijay Khanna forderte am 2. August die Betreiber von XRP-Ledger-Knoten auf, die Version xrpld 3.2.1 zu installieren, nachdem Entwickler am 31. Juli eine Flut von Validator-Manifesten beobachtet hatten.
Zusammenfassung
- Die Manifest-Flut am 31. Juli veranlasste xrpld 3.2.1, während das XRP-Ledger währenddessen weiterhin normal Ledger schloss.
- Vier Schutzmaßnahmen begrenzen nun die Manifestgröße, Nachrichtenstapel, ausgehende Weitergabe und das Wachstum des Caches für unbekannte Schlüssel im gesamten Netzwerk.
- Betreiber sollten ein Upgrade durchführen, überprüfen, dass xrpld läuft, und dann erneut neu starten, um gespeicherte Manifeste sicher zu löschen.
Der Hotfix begrenzt, wie Knoten Daten verarbeiten, speichern und weitergeben, die von unbekannten Validator-Identitäten empfangen werden.
Das XRP-Ledger schloss während des Vorfalls weiterhin normal Ledger, so XRP Ledger Operations. Die verfügbaren Beweise deuten daher auf Druck auf Knotenressourcen und Peer-to-Peer-Kommunikation hin, nicht auf einen bestätigten Verlust von Geldern, veränderte Transaktionen oder ein Versagen des Ledger-Konsenses. Die Entwickler haben weder eine CVE-Kennung noch eine Schätzung finanzieller Verluste im Zusammenhang mit dem Vorfall veröffentlicht.
XRPL 3.2.1 begrenzt die Manifest-Flut-Route
Validator-Manifeste sind kryptographisch signierte Datensätze, die die stabile Master-Identität eines Validators mit dem temporären Schlüssel verbinden, den er für tägliche Validierungsnachrichten verwendet. Wenn Betreiber diese temporären Schlüssel rotieren, veröffentlichen sie ein neues Manifest, das mit dem Master-Schlüssel signiert ist, damit andere Knoten die Änderung überprüfen können.
Vor dem Hotfix konnten Knoten gültig strukturierte Manifeste, die mit Validator-Schlüsseln verbunden waren, die sie nicht erkannten, akzeptieren, zwischenspeichern und erneut ausstrahlen. Ein Angreifer konnte dieses Verhalten ausnutzen, indem er viele unbekannte Identitäten erzeugte und Peers zwang, Speicher, Speicherplatz, Bandbreite und Verarbeitungskapazität für die Verarbeitung der Daten aufzuwenden. Der öffentliche Code-Datensatz beschreibt den Fehler als ein Problem mit der Manifest-Verbreitung.
Das offizielle xrpld 3.2.1-Release ist vom 31. Juli und wurde am 1. August früh als neuestes signiertes Release veröffentlicht. Es enthält sechs Commits in 13 geänderten Dateien, darunter vier Commits, die die Verarbeitung nicht vertrauenswürdiger Manifeste direkt einschränken.
Vier Schutzmaßnahmen verringern das Risiko der Ressourcenerschöpfung
Die erste Schutzmaßnahme lehnt ein übermäßig großes Validator-Manifest ab, bevor der Knoten es vollständig dekodiert. Dadurch wird die Verarbeitungsarbeit reduziert, die ein Angreifer auslösen kann, indem er einzelne Objekte sendet, die größer sind als von der Software erwartet.
Die zweite begrenzt die Anzahl nicht vertrauenswürdiger Manifeste, die in einer Netzwerknachricht enthalten sind. Die Obergrenze gilt, wenn Knoten die Daten empfangen und wenn sie Manifest-Nachrichten für Peers vorbereiten. Übermäßig große Stapel werden verworfen, ohne einen nicht gepatchten Peer automatisch zu trennen, was dazu beiträgt, dass aktualisierte und ältere Knoten während des Rollouts verbunden bleiben.
Eine dritte Änderung begrenzt die Anzahl unbekannter Validator-Identitäten, die im Manifest-Cache eines Knotens gehalten werden. Der endgültige Code setzt das Maximum auf 100. Sobald diese Kapazität erreicht ist, lehnt die Software Manifeste ab, die mit neuen nicht gelisteten Schlüsseln verbunden sind, während sie weiterhin vertrauenswürdige oder zuvor erkannte Validatoren verarbeitet.
Der Patch ändert auch, wie nicht vertrauenswürdige Manifest-Informationen aufbewahrt und weitergegeben werden. Vertrauenswürdige Validator-Daten bleiben verfügbar, da die Einschränkungen auf nicht gelistetes Peer-Gossip abzielen und nicht auf Manifeste von konfigurierten oder genehmigten Validatoren. Diese Unterscheidung ermöglicht die normale Rotation von Validator-Schlüsseln, während ein unkontrolliertes Cache-Wachstum blockiert wird.
Knotenbetreiber müssen einen zweiten Neustart durchführen
Khanna riet Validatoren und anderen Infrastrukturbetreibern, so schnell wie möglich auf Version 3.2.1 zu aktualisieren. Seine Anweisungen sehen ein normales Software-Update vor, gefolgt von einer Wartezeit von ein bis zwei Minuten und einer Überprüfung, dass xrpld läuft. Die Betreiber sollten den Dienst dann erneut neu starten.
Der zweite Neustart ist wichtig für Knoten, die möglicherweise unbekannte Manifeste behalten haben, bevor der Fix installiert wurde. Das Update ändert die zukünftige Handhabung, während ein Neustart des korrigierten Servers dazu beiträgt, dass alte im Speicher befindliche oder zuvor behaltene Daten den Betrieb nicht weiterhin beeinträchtigen.
Betreiber müssen möglicherweise auch bestätigen, dass ihre Systeme dem aktuellen Paketsignaturschlüssel von Ripple vertrauen. Die Versionshinweise besagen, dass Ripple den GPG-Schlüssel, der zum Signieren von xrpld-Paketen verwendet wird, am 18. Februar rotiert hat. Bestehende Installationen, die dem Ersatzschlüssel nicht vertraut haben, erhalten möglicherweise keine automatischen Upgrades erfolgreich.
Das Update betrifft Infrastrukturanbieter und nicht gewöhnliche XRP-Inhaber. Benutzer müssen aufgrund des Manifestproblems weder XRP verschieben, Wallet-Schlüssel ändern noch neue Konten erstellen. Börsen, Verwahrer, Wallet-Backends, Datenanbieter und Unternehmen, die eigene XRPL-Server betreiben, sollten stattdessen ihre Knotenversionen und den Neustartstatus bestätigen.
Die Nachbesprechung wird den Umfang des Vorfalls bestimmen
XRP Ledger Operations sagte, eine technische "Nachbesprechung wird bald folgen." Stand 2. August hatte das Projekt diesen Bericht noch nicht veröffentlicht, daher bleiben die Identität des Absenders, das Volumen der übertragenen Manifeste und die genaue Ressourcennutzung auf betroffenen Knoten unbekannt.
Der Bericht sollte auch klären, wann Entwickler die Aktivität erstmals erkannten, ob Knoten nicht verfügbar wurden und wie schnell Betreiber Version 3.2.1 übernahmen. Obwohl Ledger weiterhin geschlossen wurden, könnte eine langsame Patch-Übernahme einzelne Server erneuten Überflutungen aussetzen, selbst wenn das gemeinsame Ledger betriebsbereit bleibt.
Der Hotfix kommt kurz nach dem größeren Rollout von XRPL Version 3.2.0. Diese Veröffentlichung, die am 15. Juni herausgegeben wurde, benannte den Referenzserver von rippled in xrpld um und führte Infrastrukturänderungen ein, die Betreiber dazu verpflichteten, Software- und Dienstkonfigurationen zu aktualisieren.
Wie zuvor berichtet, verbreitete sich Version 3.2.0 zunächst schneller unter Validatoren als im breiteren Knotennetzwerk. Die Manifestflut fügt einen neuen Grund hinzu, warum verbleibende Betreiber über diese Version hinausgehen und den Hotfix installieren sollten.
Inzwischen, in verwandter Berichterstattung, hat David Schwartz seine XRPL-Infrastruktur auf Version 3.2.0 umgestellt, während Entwickler das Netzwerk auf die neue Serverbenennung und Protokollfunktionen vorbereiteten. Früher, wie crypto.news berichtete, standen Knotenbetreiber auch vor einer Frist für Version 3.1.3 im Zusammenhang mit einer Änderungsaktivierung.
Die nächsten bestätigten Updates werden die versprochene Nachbesprechung und frische Software-Übernahmedaten sein. Bis dahin bleibt die bestätigte Antwort auf die Version 3.2.1, ihre vier Manifestkontrollen und die Aufforderung an Betreiber, den Upgrade- und Neustartprozess abzuschließen, beschränkt.
