XRPL behebt Berechtigungsdelegierung nach Entdeckung eines kritischen Fehlers

XRPL hat seine Änderung zur Berechtigungsdelegation zurückgezogen, nachdem ein Bug-Bounty-Bericht bei Tests eine schwerwiegende Schwachstelle aufgedeckt hatte. Eine gehärtete Version 1.1 durchläuft nun die Sicherheitsprüfung und Qualitätssicherung.

Der Vorfall zeigt, warum Delegation auf Protokollebene Schutzmaßnahmen erfordert, die über die grundlegende Funktion selbst hinausgehen.

XRPL überarbeitet die Berechtigungsdelegation nach Fehlerbericht

Die Berechtigungsdelegation, bekannt als XLS-75, ermöglicht es einem Konto, einem anderen Konto bestimmte Befugnisse zu übertragen, damit dieses in seinem Namen handeln kann. Die Berechtigungen sollen eng begrenzt sein, statt dem Bevollmächtigten die Kontrolle über das gesamte Konto zu geben.

J. Ayo Akinyele, Leiter der Entwicklungsabteilung bei RippleX, erklärte, dass die ursprüngliche Implementierung von V1.0 zurückgezogen wurde, nachdem vor ihrer Einführung ins XRPL-Mainnet über das Bug-Bounty-Programm eine Schwachstelle gemeldet worden war. Statt diese Version direkt zu patchen, führte das Team V1.1 ein, um die ursprüngliche Implementierung von der gehärteten Version zu trennen.

Ein als Shotes bekannter Sicherheitsforscher entdeckte ein schwerwiegendes Problem im Zusammenhang mit nicht widerrufbaren Berechtigungen für Bevollmächtigte: Ein Bevollmächtigter konnte sein Konto löschen und später neu erstellen, ohne die ihm von einem anderen Konto übertragenen Berechtigungen zu verlieren. Das ursprüngliche Konto konnte diese nicht widerrufen.

Die Änderungen gehen über einen einzelnen Bug hinaus. V1.1 behebt Randfälle im Zusammenhang mit der Identität von Delegierten und verhindert, dass neuere Funktionen wie Vault- und Lending-Operationen unbeabsichtigt delegiert werden. Außerdem wird die Reservenabrechnung für delegierte Zahlungen korrigiert und ein Multi-Signing-Pfad geschlossen, der Delegierungsprüfungen umgehen konnte. Auch das Verhalten beim Widerruf wurde verschärft.

Bei der Prüfung wurde außerdem ein mittelschwerer Überlauf einer vorzeichenlosen Ganzzahl in isDelegable entdeckt. Dadurch könnte ein fehlerhafter Berechtigungswert als delegierbarer Transaktionstyp interpretiert werden. Die Forschenden erklärten jedoch, dass das Problem keine nennenswerten Auswirkungen hätte, solange sich der Delegierende nicht regelwidrig verhält.

Tests werden auf weitere Bereiche der Delegierung im XRPL ausgeweitet

Ein von Ramkumar SG am 26. August veröffentlichter QA-Bericht dokumentierte 179 gezielte Tests zur Berechtigungsdelegierung, darunter 112 Funktionstests, 48 adversariale Sicherheitstests und 19 funktionsübergreifende Tests. Die Tests deckten auch das Zusammenspiel mit Batch, Confidential MPT, der Transaktionswarteschlange und Multi-Signing ab.

XRP Ledger Operations erklärte, dass alle Befunde in V1.1 behoben und von der Sicherheitsfirma Cantina verifiziert worden seien. Das QA-Team meldete außerdem keine Regressionen in 5.088 Tests und wies darauf hin, dass keine offenen internen Bugs als kritisch eingestuft seien. Daher sei die Funktion auf dem getesteten Commit-Stand für den Produktionseinsatz bereit.

Permission Delegation wurde im Mai 2025 eingeführt, im September 2025 bis zur Behebung eines Sicherheitsproblems als nicht unterstützt eingestuft, im Oktober in PermissionDelegationV1_1 umbenannt und im Juni 2026 wieder unterstützt.

Als CryptoPotatoWie letzte Woche berichtet wurde, verfolgt ein öffentliches Dashboard des Entwicklers Denis Angell, wie gründlich XRPL-Änderungen im Devnet getestet werden, bevor sie das Mainnet erreichen. Delegation gehörte zu den Änderungen, die das Dashboard als unvollständig eingestuft hatte.

Für Nutzer und Verwahrungsanbieter bleibt die vorgesehene Funktionalität unverändert. Wie Akinyele es formulierte: V1.1 ändert nicht, was XLS-75 leisten kann, sondern die Bedingungen, unter denen diese Fähigkeit aktiviert wird.

Quelle: CryptoPotato