#xrpledgerpatchesxrpcreationbug
XRP aurait pu être créé à partir de rien. Un bug vieux de dix ans explique comment.
Le XRP Ledger a révélé une vulnérabilité critique le 9 octobre. Le bug aurait été présent depuis 2015 et aurait pu permettre à un attaquant de créer et de dépenser des XRP sans en payer la pleine valeur.
Voici ce qui a retenu mon attention.
Le problème concernait un dépassement d’entier dans le moteur de paiement. Lorsqu’un paiement utilisait des centaines d’offres spécialement conçues, le total pouvait revenir à un nombre beaucoup plus petit.
Le moteur pouvait créditer les propriétaires des offres tout en facturant beaucoup moins à l’acheteur.
Plus inquiétant encore, un contrôle de sécurité conçu pour détecter la création de nouveaux XRP utilisait une arithmétique similaire et n’a pas détecté le même dépassement.
Deux mesures de protection peuvent échouer simultanément lorsqu’elles partagent la même faiblesse sous-jacente.
Le correctif a été livré dans xrpld 3.4.1 le 25 septembre. L’équipe XRPL n’a trouvé aucune preuve que la vulnérabilité ait été exploitée sur un réseau public.
Ce que j’en retiens : la sécurité des blockchains ne consiste pas seulement à trouver des bugs. Il faut aussi s’assurer que des mesures de protection indépendantes ne présentent pas le même angle mort.
Le code source ouvert, les programmes de chasse aux bugs et les audits sont importants. Il est tout aussi essentiel de vérifier qu’un correctif résout réellement la vulnérabilité d’origine.
Le système de sécurité le plus robuste n’est pas celui qui prétend ne comporter aucun bug. C’est celui qui sait les détecter, les contenir et les corriger avant qu’ils ne soient exploités.
Pensez-vous que les protocoles crypto investissent suffisamment dans des contrôles de sécurité indépendants ?
$XRP #xrp #XRPledger #CryptoSecurity #BinanceSquare
XRP aurait pu être créé à partir de rien. Un bug vieux de dix ans explique comment.
Le XRP Ledger a révélé une vulnérabilité critique le 9 octobre. Le bug aurait été présent depuis 2015 et aurait pu permettre à un attaquant de créer et de dépenser des XRP sans en payer la pleine valeur.
Voici ce qui a retenu mon attention.
Le problème concernait un dépassement d’entier dans le moteur de paiement. Lorsqu’un paiement utilisait des centaines d’offres spécialement conçues, le total pouvait revenir à un nombre beaucoup plus petit.
Le moteur pouvait créditer les propriétaires des offres tout en facturant beaucoup moins à l’acheteur.
Plus inquiétant encore, un contrôle de sécurité conçu pour détecter la création de nouveaux XRP utilisait une arithmétique similaire et n’a pas détecté le même dépassement.
Deux mesures de protection peuvent échouer simultanément lorsqu’elles partagent la même faiblesse sous-jacente.
Le correctif a été livré dans xrpld 3.4.1 le 25 septembre. L’équipe XRPL n’a trouvé aucune preuve que la vulnérabilité ait été exploitée sur un réseau public.
Ce que j’en retiens : la sécurité des blockchains ne consiste pas seulement à trouver des bugs. Il faut aussi s’assurer que des mesures de protection indépendantes ne présentent pas le même angle mort.
Le code source ouvert, les programmes de chasse aux bugs et les audits sont importants. Il est tout aussi essentiel de vérifier qu’un correctif résout réellement la vulnérabilité d’origine.
Le système de sécurité le plus robuste n’est pas celui qui prétend ne comporter aucun bug. C’est celui qui sait les détecter, les contenir et les corriger avant qu’ils ne soient exploités.
Pensez-vous que les protocoles crypto investissent suffisamment dans des contrôles de sécurité indépendants ?
$XRP #xrp #XRPledger #CryptoSecurity #BinanceSquare