#XRPLedgerPatchesXRPCreationBug
Une offre fixe ne signifie rien si le code chargé de la faire respecter peut se tromper dans ses calculs.
Le XRP Ledger vient de révéler une vulnérabilité vieille de dix ans qui aurait pu permettre à des attaquants de créer des XRP utilisables à partir de rien.
Voici l’aspect qui, selon moi, mérite davantage d’attention.
La faille concernait un dépassement de capacité d’entier dans le moteur de paiement. En créant des centaines d’offres d’échange délibérément mal évaluées et en les exécutant dans un seul paiement, un attaquant aurait pu faire créditer aux vendeurs bien plus de XRP que ce que l’acheteur avait réellement payé.
Même le mécanisme intégré au registre pour protéger l’offre totale aurait pu ne pas détecter l’écart, car il reposait sur des calculs vulnérables au même type de dépassement.
La vulnérabilité a été corrigée dans xrpld 3.4.1, publié le 25 septembre. Les développeurs affirment n’avoir trouvé aucune preuve d’exploitation sur les réseaux publics. Soyons donc précis : il s’agissait d’une faille potentielle critique, et non de la preuve que des milliards de XRP ont réellement été volés ou créés sur le réseau en production.
La principale leçon que j’en tire ? La sécurité d’une blockchain ne repose pas seulement sur la décentralisation, la cryptographie ou la transparence des transactions. Elle dépend aussi de la fiabilité des logiciels qui traitent ces transactions.
Et il y a là une leçon dérangeante : un système peut comporter plusieurs contrôles de sécurité et malgré tout échouer si ces contrôles présentent la même faiblesse sous-jacente.
La recherche en sécurité assistée par l’IA pourrait aider à mettre au jour ces failles, mais les découvrir ne représente que la moitié du travail. La vérification indépendante, les tests rigoureux, la publication rapide de correctifs et la divulgation responsable restent essentiels.
La vraie question n’est pas de savoir si un réseau a déjà connu un bug. C’est de savoir si ses processus de sécurité peuvent le détecter, le contenir et le corriger avant qu’un attaquant ne l’exploite.
Cet incident change-t-il votre façon d’évaluer la sécurité du XRP Ledger, ou le correctif déployé avec succès renforce-t-il votre confiance ?
#XRP
Une offre fixe ne signifie rien si le code chargé de la faire respecter peut se tromper dans ses calculs.
Le XRP Ledger vient de révéler une vulnérabilité vieille de dix ans qui aurait pu permettre à des attaquants de créer des XRP utilisables à partir de rien.
Voici l’aspect qui, selon moi, mérite davantage d’attention.
La faille concernait un dépassement de capacité d’entier dans le moteur de paiement. En créant des centaines d’offres d’échange délibérément mal évaluées et en les exécutant dans un seul paiement, un attaquant aurait pu faire créditer aux vendeurs bien plus de XRP que ce que l’acheteur avait réellement payé.
Même le mécanisme intégré au registre pour protéger l’offre totale aurait pu ne pas détecter l’écart, car il reposait sur des calculs vulnérables au même type de dépassement.
La vulnérabilité a été corrigée dans xrpld 3.4.1, publié le 25 septembre. Les développeurs affirment n’avoir trouvé aucune preuve d’exploitation sur les réseaux publics. Soyons donc précis : il s’agissait d’une faille potentielle critique, et non de la preuve que des milliards de XRP ont réellement été volés ou créés sur le réseau en production.
La principale leçon que j’en tire ? La sécurité d’une blockchain ne repose pas seulement sur la décentralisation, la cryptographie ou la transparence des transactions. Elle dépend aussi de la fiabilité des logiciels qui traitent ces transactions.
Et il y a là une leçon dérangeante : un système peut comporter plusieurs contrôles de sécurité et malgré tout échouer si ces contrôles présentent la même faiblesse sous-jacente.
La recherche en sécurité assistée par l’IA pourrait aider à mettre au jour ces failles, mais les découvrir ne représente que la moitié du travail. La vérification indépendante, les tests rigoureux, la publication rapide de correctifs et la divulgation responsable restent essentiels.
La vraie question n’est pas de savoir si un réseau a déjà connu un bug. C’est de savoir si ses processus de sécurité peuvent le détecter, le contenir et le corriger avant qu’un attaquant ne l’exploite.
Cet incident change-t-il votre façon d’évaluer la sécurité du XRP Ledger, ou le correctif déployé avec succès renforce-t-il votre confiance ?
#XRP