Les développeurs du XRP Ledger (XRPL) ont défendu le correctif de sécurité d'urgence déployé pour corriger un bug capable de créer du XRP au-delà de l'offre fixe du réseau, faisant valoir qu'ils ne pouvaient pas attendre le vote habituel des validateurs de deux semaines sans exposer la faille à d'éventuels attaquants.

Contrairement aux réseaux qui émettent de nouvelles pièces au fil du temps, le XRP Ledger a été lancé avec l'intégralité de son offre de 100 milliards de XRP déjà en existence — c'est pourquoi un chemin de code capable de créer des tokens supplémentaires portait atteinte à une propriété fondamentale de l'actif.

Le correctif a été publié le 25 septembre, trois jours après un signalement via le programme de bug bounty, et est entré en vigueur immédiatement sur tout serveur qui l'installait. Selon les développeurs, il s'agissait du premier contournement délibéré du processus d'amendement standard du réseau depuis l'introduction de ce système il y a plus de dix ans. Selon ce processus, les modifications du protocole sont publiées sous forme d'amendements et ne s'activent qu'après que plus de 80 % des validateurs les soutiennent pendant deux semaines consécutives — le même seuil que la XRPL Foundation a ensuite invoqué pour justifier le passage obligatoire à la version 3.4.1.

« Avec un vote d'amendement normal, le correctif aurait été public pendant des semaines avant d'entrer en vigueur, ce qui aurait compromis la sécurité du réseau », ont déclaré les développeurs du XRPL dans un post X dimanche.

Ce correctif accéléré a soulevé des questions sur le degré de décentralisation du XRP Ledger. Sur son site web, le XRPL se décrit comme une blockchain publique totalement décentralisée — une caractérisation qui a été au cœur des arguments selon lesquels son token natif, le XRP, ne devrait pas être classé comme un titre. Ces arguments ont un poids réglementaire : la Securities and Exchange Commission américaine a poursuivi Ripple en justice en décembre 2020, l'accusant d'offres de titres non enregistrées de XRP, et le degré de décentralisation du XRP a été un argument récurrent dans ce dossier.

Le correctif de sécurité a « soulevé beaucoup de questions »

Justin Bons, fondateur de Cyber Capital, a déclaré jeudi que promouvoir le XRP auprès des investisseurs particuliers comme décentralisé revenait à une « fraude pure et simple ». Il a soutenu que la version d'urgence du 25 septembre n'était distribuée qu'en binaires, avec un code source temporairement retenu, et que les opérateurs avaient été pressés de mettre à jour.

La XRPL Foundation a toutefois indiqué que la décision de contourner le processus d'amendement standard avait été prise conjointement par la Foundation, RippleX, lespeurs principaux et les validateurs après évaluation de la gravité du bug.

« Aucune partie ne pouvait prendre cette décision seule. Chaque validateur et opérateur de nœud choisit le logiciel qu'il exécute, et la version 3.4.1 n'est devenue obligatoire que par un vote d'amendement normal avec plus de 80 % de soutien des validateurs pendant deux semaines. Les modifications du protocole passent toujours par des amendements », a déclaré la fondation.

XRP Kuwait, un opérateur de validateur indépendant, a également rejeté les affirmations selon lesquelles les mises à jour coordonnées signalaient un contrôle centralisé.

« Nous ne sommes pas d'accord avec l'affirmation selon laquelle le fait que des opérateurs coordonnent une mise à jour constitue en soi une preuve de contrôle centralisé », a-t-il déclaré dans un post X. « La coordination n'est pas la même chose que le contrôle. Des opérateurs indépendants peuvent évaluer une situation, communiquer entre eux et parvenir à la même conclusion sans renoncer à leur indépendance. »

Le bug aurait pu créer une quantité illimitée de XRP

Selon le rapport de divulgation de vulnérabilités du projet, le bug était un dépassement d'entier dans le moteur de paiement du XRP Ledger, présent depuis 2015.

Les soldes XRP sont stockés sous forme d'entiers 64 bits avec un maximum fixe. Lorsqu'une somme dépassait ce maximum, le calcul revenait à un nombre plus petit au lieu d'échouer.

Un attaquant pouvait exploiter cette faille en créant des centaines d'offres à des prix spécialement conçus, chacune demandant une très grande quantité de XRP, puis en envoyant un seul paiement qui les consommait toutes. Le moteur créditait à chaque propriétaire d'offre le montant intégral tout en facturant à l'acheteur uniquement le minuscule total enveloppé — la différence se matérialisant sous forme de XRP nouvellement créé et utilisable.

L'attaque nécessitait des offres délibérément construites et ne pouvait pas être déclenchée par une activité de trading normale, selon le rapport. Les développeurs ont déclaré n'avoir trouvé aucune preuve que le problème ait jamais été exploité sur un réseau public.

La façon dont une faille dans l'un des composants essentiels du registre est restée indétectée pendant près de dix ans reste une question ouverte dans le débat qu'a suscité cette divulgation.