Le directeur de l'ingénierie de Ripple, Vijay Khanna, a exhorté les opérateurs de nœuds du XRP Ledger le 2 août à installer la version 3.2.1 de xrpld après que les développeurs ont observé une inondation de manifestes de validateurs le 31 juillet.
Résumé
- L'inondation de manifestes du 31 juillet a conduit à la version 3.2.1 de xrpld, tandis que le XRP Ledger a continué à fermer les registres normalement tout au long de l'incident.
- Quatre mesures de protection plafonnent désormais la taille des manifestes, les lots de messages, le partage sortant et la croissance du cache des clés inconnues à l'échelle du réseau.
- Les opérateurs doivent mettre à niveau, vérifier que xrpld fonctionne, puis redémarrer à nouveau pour effacer en toute sécurité les manifestes persistants.
Le correctif limite la manière dont les nœuds traitent, stockent et partagent les données reçues d'identités de validateurs inconnues.
Le XRP Ledger a continué à fermer les registres normalement pendant l'événement, selon XRP Ledger Operations. Les preuves disponibles indiquent donc une pression sur les ressources des nœuds et les communications de pair à pair plutôt qu'une perte confirmée de fonds, des transactions modifiées ou une défaillance du consensus du registre. Les développeurs n'ont pas publié d'identifiant CVE ni d'estimation de pertes financières liées à l'incident.
XRPL 3.2.1 limite la voie d'inondation des manifestes
Les manifestes de validateurs sont des enregistrements signés cryptographiquement qui relient l'identité maître stable d'un validateur à la clé temporaire qu'il utilise pour les messages de validation quotidiens. Lorsque les opérateurs font pivoter ces clés temporaires, ils publient un nouveau manifeste signé par la clé maître afin que les autres nœuds puissent vérifier le changement.
Avant le correctif, les nœuds pouvaient accepter, mettre en cache et rediffuser des manifestes valides associés à des clés de validateurs qu'ils ne reconnaissaient pas. Un attaquant pouvait exploiter ce comportement en produisant de nombreuses identités inconnues et en forçant les pairs à dépenser de la mémoire, du stockage, de la bande passante et de la capacité de traitement pour gérer les données. Le code public décrit le défaut comme un problème de propagation des manifestes.
La version officielle xrpld 3.2.1 est datée du 31 juillet et a été publiée comme la dernière version signée au début du 1er août. Elle contient six commits répartis sur 13 fichiers modifiés, dont quatre commits qui restreignent directement le traitement des manifestes non fiables.
Quatre mesures de protection réduisent le risque d'épuisement des ressources
La première mesure de protection rejette un manifeste de validateur surdimensionné avant que le nœud ne le décode complètement. Cela réduit le travail de traitement qu'un attaquant peut déclencher en envoyant des objets individuels plus grands que ce que le logiciel attend.
La deuxième limite le nombre de manifestes non fiables transportés dans un seul message réseau. Le plafond s'applique lorsque les nœuds reçoivent les données et lorsqu'ils préparent des messages de manifeste pour les pairs. Les lots surdimensionnés sont abandonnés sans déconnecter automatiquement un pair non corrigé, ce qui aide les nœuds mis à niveau et les nœuds plus anciens à rester connectés pendant le déploiement.
Une troisième modification limite le nombre d'identités de validateurs inconnues conservées dans le cache de manifestes d'un nœud. Le code final fixe le maximum à 100. Une fois cette capacité atteinte, le logiciel rejette les manifestes liés à de nouvelles clés non répertoriées tout en continuant à traiter les validateurs de confiance ou précédemment reconnus.
Le correctif modifie également la manière dont les informations de manifeste non fiables sont conservées et propagées. Les données de validateurs de confiance restent disponibles car les restrictions ciblent les rumeurs de pairs non répertoriés plutôt que les manifestes de validateurs configurés ou approuvés. Cette distinction permet à la rotation normale des clés de validateurs de continuer tout en bloquant la croissance incontrôlée du cache.
Les opérateurs de nœuds doivent effectuer un deuxième redémarrage
Khanna a conseillé aux validateurs et aux autres opérateurs d'infrastructure de mettre à niveau vers la version 3.2.1 « dès que possible ». Ses instructions prévoient une mise à jour logicielle normale, suivie d'une attente d'une à deux minutes et d'une vérification que xrpld fonctionne. Les opérateurs doivent ensuite redémarrer le service à nouveau.
Le deuxième redémarrage est important pour les nœuds qui ont pu conserver des manifests inconnus avant l'installation du correctif. La mise à jour modifie la gestion future, tandis que le redémarrage du serveur corrigé aide à garantir que les anciennes données en mémoire ou précédemment conservées ne continuent pas à affecter les opérations.
Les opérateurs peuvent également avoir besoin de confirmer que leurs systèmes font confiance à la clé de signature de paquets actuelle de Ripple. Les notes de version indiquent que Ripple a fait pivoter la clé GPG utilisée pour signer les paquets xrpld le 18 février. Les installations existantes qui n'ont pas fait confiance à la clé de remplacement peuvent ne pas recevoir les mises à jour automatiques avec succès.
La mise à jour s'applique aux fournisseurs d'infrastructure plutôt qu'aux détenteurs ordinaires de XRP. Les utilisateurs n'ont pas besoin de déplacer leurs XRP, de changer leurs clés de portefeuille ou de créer de nouveaux comptes en raison du problème de manifest. Les bourses, les dépositaires, les backends de portefeuille, les fournisseurs de données et les entreprises qui exécutent leurs propres serveurs XRPL devraient plutôt confirmer leurs versions de nœuds et leur statut de redémarrage.
Le post-mortem déterminera la portée de l'incident
XRP Ledger Operations a déclaré qu'un « post-mortem technique suivra bientôt ». Au 2 août, le projet n'avait pas publié ce rapport, donc l'identité de l'expéditeur, le volume de manifests transmis et l'utilisation exacte des ressources à travers les nœuds affectés restent non divulgués.
Le rapport devrait également clarifier quand les développeurs ont détecté l'activité pour la première fois, si des nœuds sont devenus indisponibles et à quelle vitesse les opérateurs ont adopté la version 3.2.1. Bien que les registres aient continué à se fermer, une adoption lente des correctifs pourrait laisser des serveurs individuels exposés à de nouvelles inondations même lorsque le registre partagé reste opérationnel.
Le correctif arrive peu après le déploiement de la version 3.2.0 plus large de XRPL. Cette version, publiée le 15 juin, a renommé le serveur de référence de rippled à xrpld et a introduit des changements d'infrastructure qui ont obligé les opérateurs à mettre à jour les logiciels et les configurations de service.
Comme précédemment rapporté, la version 3.2.0 s'est initialement propagée plus rapidement parmi les validateurs que dans le réseau de nœuds plus large. L'inondation de manifests ajoute une nouvelle raison pour les opérateurs restants d'aller au-delà de cette version et d'installer le correctif.
Pendant ce temps, dans une couverture connexe, David Schwartz a déplacé son infrastructure XRPL vers la version 3.2.0 alors que les développeurs préparaient le réseau pour le nouveau nom de serveur et les fonctionnalités de protocole. Plus tôt, comme crypto.news l'a rapporté, les opérateurs de nœuds ont également fait face à une échéance de version 3.1.3 liée à une activation d'amendement.
Les prochaines mises à jour vérifiées seront le post-mortem promis et les nouvelles données d'adoption des logiciels. En attendant, la réponse confirmée reste limitée à la version 3.2.1, ses quatre contrôles de manifests et la demande aux opérateurs de terminer la mise à niveau et le processus de redémarrage.
