Les développeurs du XRP Ledger ont divulgué et corrigé une vulnérabilité critique qui, si elle n'avait pas été traitée, aurait permis à un attaquant de créer des XRP de nulle part — un défaut demeuré inactif dans le code du réseau pendant près d'une décennie.

Dans une divulgation publiée vendredi, les mainteneurs du registre ont indiqué qu'un chercheur avait signalé le bug en septembre via le programme de bug bounty du XRPL. Le problème était un dépassement d'entier dans le moteur de paiement, le composant du logiciel responsable du traitement des paiements.

L'erreur arithmétique ne se manifestait que dans des conditions inhabituelles. Lorsqu'un seul paiement consommait des centaines d'offres spécialement conçues du carnet d'ordres, la somme due par l'acheteur dépassait la valeur maximale que le système pouvait stocker et « rebouclait » vers un nombre minuscule. Le moteur payait chaque vendeur intégralement mais facturait à l'acheteur presque rien, la différence représentant des XRP nouvellement émis qui n'auraient jamais dû exister.

Aggravant le problème, le contrôle de sécurité intégré du registre — conçu pour vérifier qu'aucune transaction ne crée de XRP — reposait sur la même arithmétique défectueuse. Il rebouclait de manière identique et ne détectait rien. Selon les mainteneurs, un attaquant aurait pu créer des XRP dépensables bien au-delà de l'offre totale du token en une seule transaction, puis les déplacer, les échanger ou les envoyer vers des plateformes. Ce contrôle est le mécanisme sur lequel le registre compte pour garantir qu'aucune transaction ne peut frapper de nouveaux XRP, et il a échoué silencieusement aux côtés du code même qu'il était censé surveiller.

Les ingénieurs de RippleX ont confirmé que le bug était présent depuis la rédaction du moteur de paiement actuel en 2015. Il est passé inaperçu car aucun paiement ordinaire ne s'approche même de loin du déclenchement du dépassement, et il n'existe aucune preuve qu'il ait jamais été exploité, a déclaré l'équipe.

Le correctif est arrivé dans la version 3.4.1 le 25 septembre, et plus de 80 % des validateurs de confiance du réseau l'exécutaient dès ce jour. Fait notable, le correctif a contourné le processus d'amendement habituel du registre, qui exige que les validateurs votent et attendent deux semaines avant qu'un changement ne prenne effet. C'était la première fois qu'une modification du traitement des transactions était délibérément déployée de cette manière depuis l'introduction du système il y a plus de dix ans. Les mainteneurs ont déclaré que la gravité justifiait cette dérogation, puisque la publication du correctif open source aurait révélé le bug tout en le laissant exploitable pendant des semaines. Le défaut étant désormais public, tout validateur encore sur une version antérieure a à la fois la raison et le remède à portée de main — la mise à niveau vers la 3.4.1 supprime l'arithmétique défectueuse du traitement des paiements de ce nœud.

Cette divulgation rappelle une alerte à la contrefaçon qui a secoué Zcash plus tôt cette année, lorsque la crypto de confidentialité s'est empressée de corriger un bug deité dans son pool blindé qui aurait pu permettre la création de pièces falsifiées. Cet épisode a fait chuter le ZEC avant que la mise à niveau Ironwood du réseau ne le résolve. Les deux incidents visaient la même catégorie de garantie : que l'actif d'une blockchain ne peut être fabriqué de nulle part, quelle que soit l'ingéniosité avec laquelle une transaction est conçue.

Le XRP n'a pas échappé aux secousses cette semaine. Le token s'échangeait à 1,38 $ lundi, en baisse de 1,6 % sur 24 heures — la pire performance parmi les principales cryptomonnaies — et en recul de 9,4 % sur les sept derniers jours.