Les validateurs du XRP Ledger ont activé l'amendement fixCleanup3_4_0 le 4 novembre à 14h52 UTC, fermant une fenêtre de près de quatre semaines durant laquelle un burn délégué de tokens pouvait pousser le solde d'un compte en dessous de zéro. Coindoo a confirmé la transaction d'activation dans le ledger validé 108,112,129, et le serveur Mainnet public de Ripple liste l'amendement comme activé.

L'activation est intervenue après un vote ayant brièvement perdu sa supermajorité fin octobre, un contretemps suivi dans le rapport de pré-activation de Coindoo. Ce rapport détaillait la liste de vérifications que les émetteurs étaient invités à effectuer. Le code et le test livrés avec le correctif répondent à une question plus précise : à qui appartiennent les tokens réellement créés par le dépassement.

Près de quatre semaines sans vérification du solde zéro

La délégation a été activée le 8 octobre sous l'amendement PermissionDelegationV1_1, selon le tableau de bord des amendements XRPL. Du 8 octobre au 4 novembre, un délégué détenant PaymentBurn pouvait, dans certaines configurations, pousser un rachat au-delà de zéro. La référence des permissions XRPL recommandait donc de ne pas déléguer cette permission tant que cet amendement n'était pas activé. Cette condition a été remplie le 4 novembre.

Le commit rippled à l'origine du correctif, signé sous le pseudo GitHub yinyiqian1, ajoute la vérification manquante. Lorsqu'un délégué détient uniquement PaymentBurn, le ledger compare le montant du paiement au solde réellement détenu par le compte et rejette tout montant supérieur. La documentation XRPL décrivait déjà le burn comme s'arrêtant à zéro ; pour les paiements délégués, le code n'appliquait pas cette limite avant cet amendement.

Au cœur du test : Alice, un gateway et un paiement surdimensionné

Le test du commit utilise trois comptes. Alice détient 50 USD émis par un compte appelé gateway. Gateway, à son tour, a ouvert une ligne de confiance acceptant jusqu'à 200 USD émis par alice, ce que les commentaires du code décrivent comme donnant au moteur de paiement « une liquidité d'émission disponible une fois la trustline à zéro ».

Alice accorde ensuite à un troisième compte, bob, la permission PaymentBurn, et bob envoie un paiement d'alice vers gateway pour le double de ce qu'elle détient. La trace montre comment le ledger a traité ce paiement, puis les paiements suivants, sous chaque ensemble de règles.

Anciennes règles · PaymentBurn uniquement

• 100 USD : accepté
• Les 50 d'alice rachetés, puis 50 USD émis par alice créés
• État final : gateway détient 50 USD émis par alice

Nouvelles règles · PaymentBurn uniquement

• 100 USD : rejeté
• 20 USD : accepté, il reste 30
• 30 USD : accepté, solde à zéro
• 1 USD : rejeté

Nouvelles règles · PaymentBurn + PaymentMint

• 100 USD : accepté
• Passe sous zéro, car l'émission est autorisée et gateway accepte les IOUs d'alice

Les nouveaux tokens constituaient la dette d'alice

Sous les anciennes règles, le paiement n'ajoutait aucune unité des USD de gateway. L'obligation de gateway envers alice est passée de 50 à zéro. Ce qui est apparu à la place était 50 USD émis par alice et détenus par gateway : alice a terminé la transaction en dette envers l'émetteur, sur la base d'un paiement signé par un délégué qu'elle n'avait autorisé qu'à racheter.

Le ledger traite ces actifs comme deux actifs distincts. La documentation XRPL sur le format des actifs identifie un token de ligne de confiance par son code de devise et son compte émetteur ; les USD d'alice et ceux de gateway partagent donc un code mais pas un émetteur. Le XRP natif, qui n'a pas d'émetteur, était totalement à l'écart de la faille.

Dans le cas documenté, le risque reposait donc sur deux parties : le compte ayant délégué l'autorité de burn, qui pouvait hériter d'un passif qu'il n'avait jamais approuvé, et l'émetteur recevant ces IOUs. Les détenteurs des USD de gateway ne faisaient pas face à de nouvelles unités du token qu'ils détenaient.

La condition préalable qui a limité la faille

Le dépassement dépendait d'un paramètre côté gateway. Sans une ligne de confiance acceptant les IOUs d'alice, le paiement ne pouvait pas créer de USD émis par alice. Un émetteur doit soumettre lui-même cette ligne de confiance, ce qui constitue le meilleur argument en faveur d'une portée pratique limitée de la faille.

Cet argument a une réserve. La documentation XRPL sur la délégation listait également les Multi-Purpose Tokens (MPTs) parmi les actifs qu'un délégué en burn-only pouvait émettre avant le correctif, tandis que le test du commit ne couvre que le cas de la ligne de confiance. Aucune des deux sources ne décrit d'incident réel, mais la lecture centrée sur la ligne de confiance ne doit pas être étendue aux émetteurs de MPTs sans un test spécifique.

Une permission couvre toujours toutes les devises

L'amendement plafonne le montant qu'un délégué en burn-only peut racheter. Il ne touche pas aux tokens concernés par la permission. Les permissions granulaires sont codées en dur, et la même documentation précise qu'un compte ne peut pas accorder à un délégué le droit d'envoyer certaines devises tout en en excluant d'autres.

Pour un compte d'opérations détenant des tokens USD et EUR, ou des stablecoins de deux émetteurs, une seule autorisation PaymentBurn permet au délégué de racheter l'ensemble, chacun jusqu'à son solde. Toute séparation par devise doit passer par la répartition des avoirs entre plusieurs comptes. La permission de type de transaction Payment va encore plus loin, couvrant les paiements de ce type en général, si bien qu'une revue vérifiant uniquement les deux valeurs granulaires peut la manquer. L'article précédent de Coindoo sur la répartition de l'autorité opérationnelle entre les comptes dans XRPL explique comment les institutions structurent ces rôles.

Ce qui révélerait une exploitation de la faille

Chaque autorisation est publique. L'entrée Delegate du ledger enregistre le compte accordant l'autorisation, le délégué et sa liste de permissions, ce qui fait de la détection d'un usage abusif une question vérifiable onchain par tous.

Le schéma onchain :

• Un paiement validé après le 8 octobre et avant le ledger 108,112,129.
• Signé par un délégué détenant PaymentBurn, mais ni PaymentMint ni Payment, à ce moment.
• Envoyé à l'émetteur du token, laissant le compte délégant avec un solde négatif sur cette ligne de confiance.

Un paiement correspondant aux trois critères confirmerait que le dépassement s'est produit sur le Mainnet. Une revue de toutes les autorisations PaymentBurn dans cette fenêtre n'en trouvant aucune permettrait d'exclure une exploitation pour les tokens de ligne de confiance, les MPTs faisant l'objet d'une vérification distincte. Comme DelegateSet remplace intégralement une liste de permissions, comme l'expliquait le rapport de pré-activation, la vérification doit utiliser les permissions en vigueur au moment de la validation de chaque paiement.

L'amendement s'applique à partir du ledger 108,112,129. Tout paiement validé avant demeure exactement tel qu'enregistré, y compris ceux ayant franchi le zéro. Pour les opérateurs examinant les transactions autour de ce changement, le numéro du ledger validé constitue donc la limite pertinente pour déterminer quelles règles s'appliquaient.

Source : Coindoo