L'équipe de développement du XRP Ledger (XRPL) a divulgué le 9 octobre une faille de dépassement d'entier qui, dans des conditions soigneusement construites, aurait pu permettre de créer du XRP dépensable à partir de rien. Le correctif a été livré dans la version 3.4.1 de xrpld le 25 septembre, soit environ deux semaines avant la divulgation publique, et l'équipe a indiqué n'avoir trouvé aucune preuve que la vulnérabilité ait été exploitée sur un réseau public.

Les détails ont été présentés dans le rapport de divulgation de vulnérabilité du 9 octobre de XRPL.

Un calcul de paiement qui aurait pu produire du XRP à partir de rien

Le rapport décrit une faille de dépassement d'entier dans le moteur de paiement du registre. Dans des conditions soigneusement construites, un paiement consommant de nombreuses offres du carnet d'ordres aurait pu créditer des comptes en XRP que l'expéditeur n'avait pas réellement payés. Les carnets d'ordres sont une structure native de XRPL, faisant partie de la bourse intégrée au registre, de sorte que l'arithmétique défaillante se trouve dans un code qui sous-tend à la fois les échanges et les paiements sur le registre.

Chaque offre individuelle de la transaction pouvait paraître valide en soi. La défaillance est survenue lorsque le moteur a additionné les montants de XRP de l'ensemble des offres. Une fois le total supérieur à la taille maximale du nombre utilisé pour ce calcul, celui-ci pouvait revenir à une valeur bien plus petite au lieu de produire une erreur.

Dans ce scénario, le moteur créditerait toujours les propriétaires des offres du montant total de XRP, tout en ne facturant à l'acheteur que le total ramené après dépassement. La différence représentait du XRP nouvellement créé, qui pouvait ensuite être déplacé, échangé ou envoyé à une plateforme comme tout autre solde.

Pourquoi la faille était sérieuse

L'attaque ne nécessitait pas un solde important en XRP. Un attaquant aurait pu contrôler les comptes plaçant les offres, payer les réserves de compte et les frais de transaction nécessaires, puis répartir le XRP créé entre ces comptes.

La vulnérabilité résidait dans l'arithmétique des paiements plutôt que dans l'accès aux portefeuilles, laissant les clés de compte intactes. Son déclenchement nécessitait des centaines d'offres à prix délibérément définis et une transaction conçue pour les consommer ensemble ; un paiement ou un échange ordinaire de XRP n'atteindrait pas les valeurs nécessaires pour créer le dépassement.

Pour un registre, peu de défauts sont aussi sensibles qu'un défaut capable de frapper des unités dépensables, car chaque solde dépend de l'entrée du nouveau XRP en circulation uniquement selon les règles définies par le réseau.

XRPL a déclaré n'avoir trouvé aucune preuve d'exploitation sur un réseau public, et aucun compromission de clé privée, perte de fonds ou échec de consensus n'a été signalé. La faille semble avoir été présente depuis la rédaction du moteur de paiement actuel en 2015, et elle est restée non détectée car l'activité normale n'a jamais atteint la limite arithmétique.

La protection existante du registre contre la création de nouveau XRP reposait également sur le même type d'addition. Elle pouvait subir le même dépassement que le moteur de paiement, permettant à la transaction de paraître normale au lieu de signaler l'augmentation inattendue des soldes.

Pourquoi les développeurs ont utilisé un déploiement d'urgence

Les développeurs ont publié le correctif du dépassement avant de divulguer ses détails techniques, car un calendrier normal d'amendement aurait laissé un exploit connu disponible pendant des semaines. Le correctif a été livré dans la version 3.4.1 de xrpld le 25 septembre, tandis que la divulgation publique a suivi le 9 octobre.

XRPL modifie habituellement les règles de transaction par le biais d'amendements. Les validateurs mettent d'abord à niveau leur logiciel, puis maintiennent le soutien requis pendant une période déterminée avant que la nouvelle règle ne s'active au même point du registre sur tout le réseau. Ce processus évite que des serve différents parviennent à des conclusions différentes sur la même transaction.

Attendre ce processus aurait créé un problème difficile dans ce cas. xrpld étant un logiciel libre, la publication du correctif aurait pu montrer aux attaquants où chercher pendant que les anciens logiciels acceptaient encore le chemin de transaction vulnérable. L'équipe a donc fait en sorte que la nouvelle vérification de dépassement prenne effet dès la mise à niveau de chaque serveur individuel.

Cette approche plus rapide comportait un risque temporaire de compatibilité : un serveur non corrigé aurait pu accepter une transaction d'exploit qu'un serveur mis à niveau rejetait. Les développeurs ont jugé cela moins dangereux que de laisser du XRP créé entrer sur le marché. Selon le rapport, plus de 80 % des validateurs sur l'UNL par défaut avaient effectué la mise à niveau le jour de la publication de la version 3.4.1.

La divulgation couvrait une seconde faille distincte

Le rapport détaillait également un problème de validation dans la future fonctionnalité Batch de XRPL, qui permet aux utilisateurs de soumettre plusieurs transactions en une seule unité. La faille aurait pu amener des serveurs exécutant différentes versions du logiciel à être en désaccord sur une transaction Batch malformée, interrompant la validation du registre ou perturbant les applications qui analysent les données de transaction.

La faille Batch a été détectée avant que la fonctionnalité n'atteigne le mainnet. Le problème de dépassement, en revanche, affectait le code existant du moteur de paiement, c'est pourquoi son correctif ne pouvait pas attendre un cycle d'activation standard. La fonctionnalité étant encore à venir, son arrivée sur le mainnet avec le correctif de validation déjà en place constitue la partie de cette divulgation qui reste à venir.

Le rapport est arrivé alors que XRPL activait également de nouveaux outils de contrôle de compte pour les entreprises. Ces changements concernent différentes parties du registre, mais les deux dépendent du fait que les opérateurs de nœuds, les fournisseurs de portefeuilles et les développeurs suivent les mêmes règles actuelles.

Ce que les utilisateurs et opérateurs doivent faire

Les détenteurs ordinaires de XRP n'ont pas besoin de déplacer leurs fonds, de remplacer leur portefeuille ni d'échanger leurs jetons. La mise à jour concerne le logiciel qui valide les transactions, et non les soldes de comptes, les clés de portefeuille ou l'offre de XRP détenue par les utilisateurs.

• Détenteurs de XRP : aucune action n'est requise.
• Utilisateurs de plateformes d'échange : suivez les annonces de la plateforme si un échange effectue une maintenance de sa propre infrastructure XRPL.
• Opérateurs de nœuds : mettez à niveau vers xrpld 3.4.1 ou une version ultérieure pour rester synchronisés avec le réseau. Les serveurs plus anciens sont désormais bloqués par amendement suite à l'activation du correctif Batch, ce qui signifie qu'ils ne peuvent plus suivre les règles actuelles du registre tant qu'ils ne se mettent pas à jour.

Le correctif a protégé les règles d'offre du XRP avant qu'elles ne soient mises à l'épreuve

La divulgation montre à quel point le registre a été proche'une défaillance de l'intégrité de l'offre et pourquoi les validateurs ont agi rapidement. La faille a été corrigée avant que ses détails ne soient rendus publics, aucun exploit n'a été trouvé, et le moteur de paiement utilise désormais des vérifications conçues pour empêcher cette classe d'erreurs arithmétiques d'atteindre un registre validé. Ce qui reste à observer de l'extérieur, c'est la rapidité avec laquelle le reste du réseau convergera vers xrpld 3.4.1 ou une version ultérieure, sachant que les serveurs non corrigés sont déjà bloqués par amendement pour suivre le registre actuel.

Cet article est fourni à titre informatif uniquement et ne constitue ni un conseil en investissement ni un conseil technique. Les opérateurs de nœuds doivent consulter la documentation actuelle des versions XRPL avant de mettre à jour leur infrastructure de production.

Cet article est basé sur un reportage initialement publié par Coindoo.