XRP Ledger : un overflow de dix ans dans le moteur de paiement patché en rippled 3.4.1

La XRP Ledger Foundation a publié le 9 octobre un rapport de divulgation de vulnérabilité décrivant un overflow 64-bit non contrôlé dans le moteur de paiement qui aurait permis de produire des XRP ex nihilo lors de la sommation des montants d'offres consommées par un paiement. Le bug est présent depuis l'écriture du moteur de paiement en 2015. Le correctif a été livré dans rippled 3.4.1 le 25 septembre, avant la divulgation publique. La fondation affirme n'avoir trouvé aucune preuve d'exploitation sur le mainnet.

Le bug, en une ligne

Dans le moteur de paiement, un paiement cross-currency peut consommer plusieurs offres existantes du carnet d'ordres. Le moteur additionne les montants versés à ces offres en arithmétique 64-bit et compare le total à ce que fournit le payeur. La ligne de code en cause faisait cette somme sans contrôle d'overflow. En construisant un paiement dont les totaux d'offres dépassent UINT64_MAX, la valeur obtenue après wrap devient très petite : le payeur paie peu, les propriétaires d'offres sont crédités de leur montant complet, et la différence est créée, non transférée.

L'invariant « aucun XRP n'est créé en dehors de la supply initiale » utilisait la même arithmétique non contrôlée pour sa propre vérification. La deuxième ligne de défense avait le même trou que la première, et ne déclenchait donc pas sur une tentative d'inflation.

Le rapport officiel reste court sur la construction d'exploit — pratique habituelle pour un bug qui a vécu une décennie sur mainnet. Il nomme le mécanisme, pas un reproducteur.

Timeline

• 18 septembre — un bug sans lien (validation du wrapper RawTransaction dans les transactions Batch) est reporté à la Sherlock Attackathon F48 par Denis Angell et Mayukha Vadari.
• 22 septembre — l'overflow du moteur de paiement est reporté au programme de bug bounty XRPL par Cayden Liao et Veria AI.
• 25 septembre — rippled 3.4.1 est publié avec les deux correctifs. Le fix du moteur de paiement est inclus en direct ; le fix Batch est attaché à l'amendement fixBatchV1_2.
• 9 octobre — l'amendement fixBatchV1_2 s'active sur mainnet après vote des validateurs ; la XRPLF publie la divulgation.

Le fix du moteur de paiement ne nécessitait pas d'amendement — c'est un correctif de bug, pas un changement de consensus — donc le patch mainnet a pris effet au fur et à mesure que les validateurs sont montés en version. Le takeaway opérationnel pour les node operators : passer en 3.4.1 ou plus.

Pourquoi l'invariant n'a pas déclenché

Le détail architectural intéressant du rapport est que XRPL dispose d'un invariant post-transaction dédié qui vérifie qu'aucun XRP n'a été créé en dehors de la supply initiale de 100 milliards. En principe, cet invariant aurait dû tirer sur une tentative d'inflation, même si l'arithmétique primaire échouait. Il ne l'a pas fait, parce qu'il réutilisait le même pattern d'addition non vérifiée à l'origine de l'overflow. Deux lignes de défense, un seul bug.

La leçon architecturale, applicable au-delà de XRPL : un invariant de conservation ne vaut que l'arithmétique dans laquelle il est écrit. Réécrire la sommation en primitives checked_add explicites, ou en arithmétique saturante (ce que fait le fix 3.4.1), est le patch minimal. Un sweep plus large sur les autres invariants XRPL — AMM, trust-lines, escrows — qui utilisent des patterns d'accumulateur similaires serait la suite logique du postmortem.

Impact et attribution

• Exploitation observée : aucune, selon la revue on-chain de la XRPLF.
• Fenêtre d'exposition : tous les paiements mainnet passant par le carnet d'ordres, entre la réécriture du moteur de paiement en 2015 et l'upgrade 3.4.1.
• Découvreurs : Cayden Liao et Veria AI (overflow moteur de paiement) ; Denis Angell et Mayukha Vadari (fixBatchV1_2).
• Montant du bounty : non publié dans le rapport.
• CVE : non assigné au moment de la publication.

Cryptoast ajoute un détail d'exploitation — « il aurait fallu créer plusieurs centaines de comptes avec des offres spécialement conçues et seulement quelques centaines de XRP » — qui ne figure pas dans la primary source XRPLF. À prendre comme couleur de reportage, pas comme guidance de la fondation.

Contexte

Un bug arithmétique silencieux dans une primitive de paiement, capable d'imprimer l'actif de base, c'est exactement la forme de défaut que les budgets de sécurité on-chain cherchent à attraper. Le dénouement ici — soumission bounty, point-release, divulgation publique une fois le mainnet rattrapé, aucune exploitation observée — est proche d'un cas d'école. Le rapport soulève aussi une leçon structurelle : les invariants XRPL sont un filet, mais un filet tissé avec le même fil que ce qu'il doit retenir ne retient rien.

Pour un lecteur francophone qui a suivi le dossier Ripple côté marché, le fait que ce bug ait survécu à deux réécritures majeures du client et dormi sur une chaîne à cap de 100 milliards d'unités en dit long sur la durée de vie d'un edge case quand personne ne cherche spécifiquement une attaque d'inflation sur un actif non-inflationniste.

À surveiller

1. Une revue post-3.4.1 des autres invariants XRPL qui utilisent des accumulateurs non contrôlés — AMM, Clawback, et les trust-lines sont les prochains endroits à regarder.
2. Les développements du write-up technique. La XRPLF a flaggé une version plus détaillée à venir ; des diffs d'arbre d'état, si publiés, aideront les chaînes qui forkent rippled.
3. L'hygiène des forks downstream. Toute chaîne basée sur un codebase dérivé de rippled (Xahau, forks plus anciens) doit vérifier si son point de fork est avant ou après le patch du 25 septembre.
4. La cadence du bug bounty. Dix-sept jours entre rapport et divulgation publique est court pour un défaut de cet âge ; la question suivante est de savoir si la XRPLF ouvrira le template de rapport pour les prochaines découvertes.