Le XRP Ledger corrige une faille vieille de dix ans qui menaçait son plafond de 100 milliards de jetons

Les développeurs du XRP Ledger ont révélé le 9 octobre qu’une faille de dépassement d’entier dans le moteur de paiement du réseau aurait permis à un attaquant de créer des XRP à partir de rien, brisant le plafond de 100 milliards de jetons fixé au lancement du registre en 2012. La faille a été corrigée dans la version xrpld 3.4.1, publiée le 25 septembre. RippleX a indiqué n’avoir trouvé aucune preuve d’exploitation sur un réseau public, selon le rapport officiel de divulgation de vulnérabilité. Le bug a été signalé le 22 septembre via le programme de prime aux bugs du XRPL par le chercheur Cayden Liao et Veria AI. Les ingénieurs de RippleX ont reproduit l’attaque sur un serveur autonome, confirmé que les XRP nouvellement créés pouvaient être dépensés dans une transaction ultérieure, et relevé la gravité de « majeure » à « critique ». Comment le bug aurait pu créer des XRP La vulnérabilité résidait dans la gestion des dépassements du moteur de paiement. Lorsqu’un paiement unique consommait de nombreuses offres sur l’échange intégré du registre, le logiciel additionnait ce que l’acheteur devait en utilisant une addition d’entiers 64 bits sans contrôle de dépassement. Quelques centaines d’offres, chacune demandant un montant très élevé de XRP, pouvaient faire dépasser à ce total la capacité d’un nombre 64 bits et le faire revenir à une valeur minuscule. Chaque propriétaire d’offre était alors payé intégralement, tandis que l’acheteur n’était débité que du total après repli, laissant les XRP nouvellement créés sur les comptes de l’attaquant. Deux garde-fous auraient dû détecter cela, sans y parvenir. L’invariant « aucun XRP créé » du registre additionne les variations nettes de solde de la même manière : il subissait le même repli et ne voyait rien d’anormal. Un contrôle de solde par compte n’échoue que lorsqu’un compte détient plus que l’offre totale, ce que l’attaque évitait en répartissant les XRP créés sur des centaines de comptes. Pourquoi la correction a contourné le processus d’amendement Les modifications de traitement des transactions du XRP Ledger passent normalement par un processus d’amendement, une nouvelle règle restant dormante jusqu’à ce que plus de 80 % des validateurs de confiance la soutiennent pendant deux semaines. RippleX a délibérément contourné ce processus pour la première fois depuis son introduction il y a plus de dix ans, car l’exploit était bon marché, ne nécessitait aucun accès particulier et pouvait créer des XRP dépensables. xrpld étant open source, une correction publiée par la voie normale serait restée visible mais exploitable sur le mainnet pendant des semaines. Le raccourci comportait son propre risque d’arrêt du réseau en cas de versions mixtes, mais les transactions normales n’atteignent jamais le chemin de code vulnérable. Plus de 80 % des validateurs de la liste unique de nœuds par défaut exécutaient la version 3.4.1 le jour de sa publication, avant la publication du code source. Ce que cela signifie pour l’offre fixe du XRP L’épisode souligne à quel point la proposition de valeur du XRP dépend d’une offre prouvablement finie. Les 100 milliards de jetons ont tous été créés au lancement, et les institutions qui développent sur le registre considèrent ce plafond comme une garantie. Le bug existait depuis l’écriture du moteur de paiement actuel en 2015, mais RippleX n’a trouvé aucune preuve d’exploitation. La même version a aussi corrigé une faille distincte de validation de l’enveloppe des transactions Batch, activée sur le mainnet le 9 octobre. RippleX a déclaré ajouter une étape de revérification à son processus de publication, afin que chaque correctif de sécurité soit retesté sur la version candidate. Cette divulgation intervient alors que le XRP Ledger continue d’ajouter des fonctionnalités institutionnelles, notamment la délégation de permissions pour les banques et les stablecoins, tandis que l’offre de XRP et la dynamique des séquestres restent au centre de l’attention des détenteurs.