La « faille vieille de dix ans » d’XRP fait le buzz : le correctif est déployé, mais il faut surtout distinguer ces trois décalages dans le temps
« Générer des XRP à partir de rien » donne l’impression qu’un incident est en cours. Remettons les pendules à l’heure : la faille a été divulguée publiquement le 9 octobre ; le correctif du moteur de paiement avait déjà été publié avec xrpld 3.4.1. Le 10 octobre, GitHub a également rendu publics le code source de cette version et les instructions de mise à niveau. La divulgation, le correctif logiciel et l’activation des règles sur le réseau principal répondent chacun à des questions différentes.
Premièrement, la faille du moteur de paiement affectait les versions 3.4.0 et antérieures. Des chercheurs l’ont signalée le 22 septembre dans le cadre du programme de primes aux bogues. Après l’avoir reproduite, l’équipe a relevé son niveau de gravité et publié un correctif le 25 septembre. L’enquête officielle estime que le problème pourrait remonter à du code datant de 2015. Le rapport indique qu’aucune preuve d’exploitation sur un réseau public n’a été trouvée ; il s’agit d’une conclusion d’enquête, qui ne permet pas d’affirmer que toutes les activités passées ont été vérifiées et jugées exemptes d’anomalies, et encore moins d’écrire qu’une attaque visant à créer des XRP supplémentaires a bel et bien eu lieu.
Deuxièmement, le même rapport fait également état d’un problème de validation des transactions internes de Batch. Lorsque cette règle a été découverte, elle n’était pas encore activée sur le réseau principal. Le correctif a d’abord été intégré au logiciel ; fixBatchV1_2 n’a été activé sur le réseau principal que le 9 octobre. En revanche, le correctif du moteur de paiement a pris effet dès la mise à niveau des nœuds. Résumer les deux mesures par « toutes les failles n’ont été colmatées que le 9 octobre » revient à présenter une fenêtre de risque inexacte.
Troisièmement, les détenteurs ordinaires et les opérateurs de nœuds ne doivent pas confondre leurs situations. GitHub exige désormais que les serveurs passent à la version 3.4.1 ; les anciennes versions étant bloquées par un nouvel amendement, elles ne peuvent plus continuer à se synchroniser normalement. Cette exigence de mise à niveau concerne le logiciel serveur et ne signifie pas que les détenteurs doivent transférer leurs actifs vers un site inconnu pour « réparer leur portefeuille ». Si un lien prétendument lié à la sécurité vous demande votre phrase de récupération ou une autorisation, vérifiez d’abord qu’il provient d’une source officielle.
Ce que je retiens de cet événement, c’est qu’une défense en profondeur ne doit pas reposer sur la répétition d’une seule et même hypothèse : si le calcul des paiements est erroné, la couche de vérification, si elle repose sur la même hypothèse arithmétique, risque elle aussi de laisser passer le problème. Il vaut donc la peine de suivre le correctif et les procédures de vérification qui lui feront suite. Cette déduction porte sur le mécanisme de divulgation et ne constitue pas une conclusion sur les vulnérabilités d’autres protocoles.
Je continuerai à suivre les éventuels compléments de l’enquête officielle, l’avancement de la mise à niveau des anciens nœuds et les vérifications de sécurité ultérieures. Ces éléments peuvent modifier l’évaluation du risque technique ; pour savoir si la hausse des prix peut se poursuivre, il faut en revanche des données sur les transactions et la demande. La correction d’une faille de sécurité ne suffit pas, à elle seule, à justifier un signal d’achat.
Sources : divulgation de la faille par XRPL le 9 octobre et notes de publication de XRPLF/rippled 3.4.1. Vérification effectuée le 10 octobre à 22 h 36, heure de Pékin.
« Générer des XRP à partir de rien » donne l’impression qu’un incident est en cours. Remettons les pendules à l’heure : la faille a été divulguée publiquement le 9 octobre ; le correctif du moteur de paiement avait déjà été publié avec xrpld 3.4.1. Le 10 octobre, GitHub a également rendu publics le code source de cette version et les instructions de mise à niveau. La divulgation, le correctif logiciel et l’activation des règles sur le réseau principal répondent chacun à des questions différentes.
Premièrement, la faille du moteur de paiement affectait les versions 3.4.0 et antérieures. Des chercheurs l’ont signalée le 22 septembre dans le cadre du programme de primes aux bogues. Après l’avoir reproduite, l’équipe a relevé son niveau de gravité et publié un correctif le 25 septembre. L’enquête officielle estime que le problème pourrait remonter à du code datant de 2015. Le rapport indique qu’aucune preuve d’exploitation sur un réseau public n’a été trouvée ; il s’agit d’une conclusion d’enquête, qui ne permet pas d’affirmer que toutes les activités passées ont été vérifiées et jugées exemptes d’anomalies, et encore moins d’écrire qu’une attaque visant à créer des XRP supplémentaires a bel et bien eu lieu.
Deuxièmement, le même rapport fait également état d’un problème de validation des transactions internes de Batch. Lorsque cette règle a été découverte, elle n’était pas encore activée sur le réseau principal. Le correctif a d’abord été intégré au logiciel ; fixBatchV1_2 n’a été activé sur le réseau principal que le 9 octobre. En revanche, le correctif du moteur de paiement a pris effet dès la mise à niveau des nœuds. Résumer les deux mesures par « toutes les failles n’ont été colmatées que le 9 octobre » revient à présenter une fenêtre de risque inexacte.
Troisièmement, les détenteurs ordinaires et les opérateurs de nœuds ne doivent pas confondre leurs situations. GitHub exige désormais que les serveurs passent à la version 3.4.1 ; les anciennes versions étant bloquées par un nouvel amendement, elles ne peuvent plus continuer à se synchroniser normalement. Cette exigence de mise à niveau concerne le logiciel serveur et ne signifie pas que les détenteurs doivent transférer leurs actifs vers un site inconnu pour « réparer leur portefeuille ». Si un lien prétendument lié à la sécurité vous demande votre phrase de récupération ou une autorisation, vérifiez d’abord qu’il provient d’une source officielle.
Ce que je retiens de cet événement, c’est qu’une défense en profondeur ne doit pas reposer sur la répétition d’une seule et même hypothèse : si le calcul des paiements est erroné, la couche de vérification, si elle repose sur la même hypothèse arithmétique, risque elle aussi de laisser passer le problème. Il vaut donc la peine de suivre le correctif et les procédures de vérification qui lui feront suite. Cette déduction porte sur le mécanisme de divulgation et ne constitue pas une conclusion sur les vulnérabilités d’autres protocoles.
Je continuerai à suivre les éventuels compléments de l’enquête officielle, l’avancement de la mise à niveau des anciens nœuds et les vérifications de sécurité ultérieures. Ces éléments peuvent modifier l’évaluation du risque technique ; pour savoir si la hausse des prix peut se poursuivre, il faut en revanche des données sur les transactions et la demande. La correction d’une faille de sécurité ne suffit pas, à elle seule, à justifier un signal d’achat.
Sources : divulgation de la faille par XRPL le 9 octobre et notes de publication de XRPLF/rippled 3.4.1. Vérification effectuée le 10 octobre à 22 h 36, heure de Pékin.