Le 9 octobre, XRP Ledger a révélé publiquement qu’une vulnérabilité de débordement d’entier dans le moteur de paiement, qui pourrait remonter à 2015 environ, aurait théoriquement pu être exploitée pour « frapper » des $XRP dépensables à partir de rien, dépassant ainsi le plafond de 100 milliards de jetons fixé par le registre. La vulnérabilité a été signalée le 22 septembre par Cayden Liao et Veria AI dans le cadre du programme de prime aux bugs. RippleX l’a reproduite sur un nœud indépendant et a confirmé que les XRP ainsi frappés pouvaient ensuite être transférés.
L’attaque nécessitait de construire soigneusement des centaines d’ordres visant à échanger des quantités infimes de jetons contre des montants gigantesques de XRP, puis de les exécuter tous en une seule transaction de paiement. Lors de l’addition, l’entier 64 bits revenait à zéro par débordement : le compte du vendeur recevait le montant total, tandis que l’acheteur n’était débité que d’une quantité infime, la différence correspondant aux nouveaux XRP frappés. L’invariant du registre interdisant la création de nouveaux XRP reposait sur une addition similaire et subissait donc le même débordement, sans pouvoir bloquer l’opération. Selon l’équipe, aucun signe d’exploitation n’a été observé sur le réseau public. Le correctif a été publié en urgence avec xrpld 3.4.1 le 25 septembre et est entré en vigueur immédiatement après la mise à niveau, sans attendre le délai habituel prévu pour les amendements.
La divulgation du même jour portait également sur un problème de validation des champs d’encapsulation des transactions Batch. L’amendement correspondant, fixBatchV1_2, a été activé sur le réseau principal le 9 octobre. Les nœuds qui n’ont pas été mis à niveau vers la version 3.4.1 ne pourront pas se synchroniser avec le réseau, car l’amendement les bloquera.
#XRP #安全 #行情 ne constitue pas un conseil en investissement
L’attaque nécessitait de construire soigneusement des centaines d’ordres visant à échanger des quantités infimes de jetons contre des montants gigantesques de XRP, puis de les exécuter tous en une seule transaction de paiement. Lors de l’addition, l’entier 64 bits revenait à zéro par débordement : le compte du vendeur recevait le montant total, tandis que l’acheteur n’était débité que d’une quantité infime, la différence correspondant aux nouveaux XRP frappés. L’invariant du registre interdisant la création de nouveaux XRP reposait sur une addition similaire et subissait donc le même débordement, sans pouvoir bloquer l’opération. Selon l’équipe, aucun signe d’exploitation n’a été observé sur le réseau public. Le correctif a été publié en urgence avec xrpld 3.4.1 le 25 septembre et est entré en vigueur immédiatement après la mise à niveau, sans attendre le délai habituel prévu pour les amendements.
La divulgation du même jour portait également sur un problème de validation des champs d’encapsulation des transactions Batch. L’amendement correspondant, fixBatchV1_2, a été activé sur le réseau principal le 9 octobre. Les nœuds qui n’ont pas été mis à niveau vers la version 3.4.1 ne pourront pas se synchroniser avec le réseau, car l’amendement les bloquera.
#XRP #安全 #行情 ne constitue pas un conseil en investissement