Le XRP Ledger a corrigé une faille de sécurité critique remontant à 2015 qui aurait pu permettre à des attaquants de créer environ 18 billions de XRP via une seule transaction spécialement conçue, avec plus de 80 % des validateurs de confiance installant la mise à jour d'urgence le 25 septembre.
Résumé
- Les développeurs de XRPL ont corrigé un bug de paiement critique qui pouvait créer des XRP dépensables au-delà de son offre.
- Le chercheur Cayden Liao a démontré qu'environ 18 billions de XRP pouvaient être créés via une seule transaction conçue.
- L'équipe de sécurité n'a trouvé aucune preuve que la faille de dépassement ait été exploitée sur les réseaux publics.
- Plus de 80 % des validateurs par défaut ont mis à niveau vers xrpld 3.4.1 le 25 septembre, ont confirmé les développeurs.
- Un correctif distinct de validation Batch a été activé le 9 octobre après que les validateurs ont retardé son déploiement initialement prévu.
La XRP Ledger Foundation et RippleX ont confirmé la vulnérabilité dans une divulgation du 9 octobre, expliquant qu'une erreur dans le moteur de paiement du réseau aurait pu produire des XRP dépensables au-delà de son offre prévue de 100 milliards. Les développeurs ont reproduit le problème lors des tests et ont publié la version 3.4.1 pour y remédier. Leur enquête n'a trouvé aucune preuve que la faille ait été exploitée sur un réseau public. Le chercheur en sécurité Cayden Liao et Veria AI ont reçu la récompense maximale de 250 000 $ du programme de bug bounty après avoir signalé la vulnérabilité et démontré son effet potentiel.
Le XRP Ledger corrige un bug qui pouvait créer des milliers de milliards de XRP
La vulnérabilité affectait le moteur de paiement du XRP Ledger, qui traite les transferts et les transactions impliquant l'échange décentralisé intégré au réseau.
Selon la divulgation officielle, le problème provenait d'un dépassement d'entier dans un logiciel écrit en 2015. Un dépassement d'entier se produit lorsqu'un calcul produit un nombre plus grand que ce que le système informatique peut représenter avec le nombre de bits alloué.
Dans ce cas, le moteur de paiement additionnait les montants en XRP associés à plusieurs offres dans le carnet d'ordres du réseau. Le logiciel utilisait un entier de 64 bits pour calculer le montant total qu'un acheteur devait lors de l'exécution d'un paiement impliquant plusieurs offres.
Les développeurs ont découvert qu'un attaquant pouvait créer des centaines d'offres à des prix spéciaux et organiser un paiement pour les consommer. Lorsque le total calculé dépassait la valeur maximale de l'entier, le nombre pouvait revenir à un montant beaucoup plus petit. Le système créditerait toujours les vendeurs individuels avec les montants complets en XRP spécifiés dans leurs offres, même si l'acheteur ne payait que le montant réduit produit par le dépassement. La différence créerait des XRP qui n'existaient pas auparavant.
Selon la XRPL Foundation, la cryptomonnaie résultante pouvait être transférée vers d'autres comptes, échangée ou envoyée vers des plateformes d'échange. Le rapport décrivait le résultat potentiel : « Un attaquant aurait pu créer des XRP dépensables bien au-delà de l'offre totale. »
La vulnérabilité ne pouvait pas être déclenchée par des échanges ordinaires, selon les développeurs. Un attaquant aurait eu besoin de créer plusieurs centaines de comptes, de placer des offres à des prix inhabituels et de soumettre une transaction soigneusement construite pour les traiter ensemble. Les contrôles de sécurité existants ont échoué parce que la vérification de l'offre du système utilisait le même type d'arithmétique qui avait causé l'erreur initiale.
Par ailleurs, une vérification distincte du solde du compte pouvait être contournée en répartissant les XRP nouvellement créés sur plusieurs portefeuilles.
Un chercheur découvre une exploitation potentielle de 18 billions de XRP
La vulnérabilité est venue à l'attention des développeurs après que le chercheur en sécurité Cayden Liao et Veria AI ont testé le logiciel open source du XRP Ledger.
Veria Labs a publié ses conclusions le 10 octobre, décrivant comment son système automatisé de tests de sécurité a découvert le problème le 21 septembre. Le lendemain, les chercheurs ont développé une preuve de concept fonctionnelle sur un réseau de test local.
Selon l'entreprise, la démonstration a montré qu'environ 18 000 milliards de XRP pouvaient être créés via une transaction spécialement conçue. Le montant équivalait à environ 184 fois l'offre totale prévue de XRP, selon le calcul des chercheurs. Ce chiffre décrit les résultats de tests de sécurité contrôlés, et non une augmentation réelle de l'offre en circulation de la cryptomonnaie. Liao a soumis la vulnérabilité via le programme officiel de prime aux bogues XRPL le 22 septembre.
Les ingénieurs de RippleX ont reproduit le problème sur un serveur autonome et confirmé que les XRP nouvellement générés pouvaient être dépensés dans un paiement ultérieur.
Le rapport initial classait la vulnérabilité comme majeure, mais les développeurs ont élevé sa gravité à critique après avoir confirmé les conséquences potentielles. Veria Labs a déclaré que la vulnérabilité aurait pu mettre en péril toute la valeur marchande du XRP si des attaquants l'avaient exploitée avec succès. L'estimation de l'entreprise était basée sur une capitalisation boursière du XRP d'environ 94 milliards de dollars à l'époque.
Cependant, le chiffre de 94 milliards de dollars représente l'estimation du chercheur de l'exposition financière potentielle, et non des pertes confirmées. L'équipe de sécurité n'a trouvé aucune preuve de création non autorisée de XRP sur les réseaux publics. Le 8 octobre, Veria AI a reçu la prime maximale de 250 000 dollars pour avoir identifié et divulgué de manière responsable le problème.
RippleX publie un correctif d'urgence sans processus d'approbation normal
Après avoir confirmé la vulnérabilité, les ingénieurs de RippleX ont développé un correctif entre le 22 et le 23 septembre. Le correctif a été intégré à la version 3.4.1 de xrpld, publiée le 25 septembre.
Selon la divulgation officielle, les développeurs ont ajouté des vérifications qui empêchent le moteur de paiement d'accepter des calculs dépassant la plage d'entiers autorisée. Le logiciel mis à jour rejette les calculs concernés et renvoie un échec de paiement ordinaire au lieu de créer des XRP supplémentaires. Les ingénieurs ont renforcé la vérification de l'offre du réseau en remplaçant l'arithmétique existante par un compteur plus large conçu pour détecter des erreurs similaires. Des calculs de solde supplémentaires ont été examinés par précaution.
Cependant, la décision de déployer le correctif a introduit une situation inhabituelle pour la gouvernance du XRP Ledger. Normalement, les modifications du traitement des transactions doivent passer par le système d'amendement du réseau. Un amendement nécessite le soutien de plus de 80 % des validateurs de confiance pendant deux semaines consécutives avant son activation.
Pour la vulnérabilité de dépassement de paiement, les développeurs ont décidé d'appliquer le correctif immédiatement lorsque les validateurs ont mis à jour leur logiciel. La Fondation XRPL a expliqué que le processus normal aurait exposé la vulnérabilité tout en la laissant exploitable pendant la période d'approbation.
Comme le logiciel XRP Ledger est open source, la publication d'un correctif peut révéler l'emplacement et la nature d'une vulnérabilité.
Les développeurs ont conclu qu'attendre le processus d'amendement habituel aurait pu créer des risques de sécurité supplémentaires. L'approche d'urgence comportait une préoccupation distincte : les validateurs exécutant différentes versions du logiciel pourraient ne pas s'accorder sur la manière de traiter une transaction malveillante.
Dans un scénario extrême, le désaccord pourrait temporairement empêcher le réseau de confirmer de nouveaux registres. La fondation a déclaré que la décision avait été prise en consultation avec RippleX, les opérateurs de validateurs et d'autres contributeurs du XRPL. Au 25 septembre, plus de 80 % des validateurs sur la liste de nœuds uniques par défaut avaient mis à jour vers la version 3.4.1.
Le code source public a ensuite été publié après la réponse de sécurité immédiate. Les archives de publication de la Fondation XRPL décrivent la version 3.4.1 comme une mise à jour d'urgence traitant de problèmes de protocole sensibles à la sécurité.
XRP Ledger résout une deuxième faille de sécurité avant l'activation de Batch
La divulgation du 9 octobre couvrait une autre vulnérabilité impliquant la fonctionnalité de transaction Batch du XRP Ledger. Batch permet aux développeurs de combiner jusqu'à huit transactions en une seule opération. La fonctionnalité prend en charge différents modes d'exécution, y compris des arrangements dans lesquels chaque transaction doit réussir pour que l'opération complète soit acceptée.
Lors des tests de sécurité, les chercheurs ont découvert une erreur de validation concernant la façon dont les transactions individuelles étaient empaquetées dans un Batch. Le protocole exigeait que chaque transaction utilise un champ spécifique nommé RawTransaction.
Cependant, le logiciel pouvait accepter d'autres noms de champs sous certaines conditions. Les enquêteurs ont découvert que différentes versions de serveur pouvaient traiter différemment ces transactions mal formatées.
Selon la XRPL Foundation, le désaccord qui en résultait pourrait interrompre la validation du réseau si la fonctionnalité devenait active avant que le problème ne soit corrigé. Le problème a été initialement identifié lors du Sherlock Attackathon, puis examiné par le contributeur de la XRPL Foundation Denis Angell. L'ingénieur de RippleX Mayukha Vadari a déterminé que la vulnérabilité créait un risque potentiel de consensus entre les versions de serveur.
Les développeurs ont réagi en introduisant l'amendement fixBatchV1_2. L'amendement exige que chaque transaction Batch utilise le format de champ approuvé et rejette les transactions mal empaquetées. Les validateurs ont temporairement retiré leur soutien au calendrier d'activation antérieur BatchV1_1 pendant que les développeurs terminaient la correction.
fixBatchV1_2 et BatchV1_1 ont tous deux été activés sur le mainnet du XRP Ledger le 9 octobre. L'activation de XRP Ledger Batch a reçu le soutien de 30 validateurs, cinq s'opposant à la mise à niveau, selon les chiffres de XRPScan inclus dans le rapport réseau vérifié.
Des recherches antérieures sur l'examen de sécurité de Batch ont détaillé la version d'urgence du 25 septembre et les garanties nécessaires avant que la fonctionnalité puisse s'activer. La version initiale avait déjà été confrontée à des préoccupations de sécurité, notamment des problèmes d'autorisation de transaction découverts lors des examens des développeurs.
Un audit de sécurité distinct du XRP Ledger en août a documenté 96 vulnérabilités valides identifiées lors d'une compétition Sherlock couvrant les fonctionnalités de protocole proposées.
Pour la dernière vulnérabilité Batch, la XRPL Foundation a confirmé que les amendements concernés n'étaient pas actifs sur le mainnet lorsque le problème a été découvert. Aucun fonds d'utilisateur n'a été perdu, aucune clé privée n'a été compromise et aucune défaillance de consensus ne s'est produite à cause de ce défaut particulier. L'activation du 9 octobre signifie que les serveurs exécutant des versions logicielles plus anciennes sont désormais bloqués par l'amendement et doivent passer à la version 3.4.1 ou ultérieure pour rester synchronisés.
La XRPL Foundation a déclaré qu'elle introduisait une exigence de vérification supplémentaire pour les futures versions logicielles : les problèmes de sécurité précédemment signalés doivent être testés à nouveau sur les candidats à la version avant d'être classés comme corrigés.
Selon la fondation, la procédure s'appliquera aux conclusions des audits, des programmes de bug bounty, des tests de sécurité assistés par IA et d'autres évaluations de vulnérabilité.
