Le client de consensus Ethereum Lighthouse a publié un correctif de sécurité le 9 nov. et a exhorté les opérateurs de tous ses nœuds de balise à effectuer la mise à jour dès que possible.
La version v8.3.3 rend ce travail une priorité élevée pour les utilisateurs qui mettent en staking et ceux qui n'en font pas, mais l'avis de publication classe les mises à jour du client validateur comme une priorité faible pour les utilisateurs en staking.
En tant que client de consensus, Lighthouse se connecte à d'autres clients dans le réseau proof-of-stake d'Ethereum. Son nœud de balise fonctionne avec un moteur d'exécution pour valider les transactions dans les blocs, tandis que le client de validateur se connecte au nœud de balise et gère les clés, selon le Lighthouse Book.
Les opérateurs peuvent également exécuter un nœud balise sans client de validateur. La documentation de Lighthouse inclut l'analyse de données et les applications parmi ces utilisations non de staking, et ces opérateurs reçoivent les mêmes instructions à haute priorité pour le nœud balise que les utilisateurs de staking dans le tableau de la mise à jour v8.3.3.
Les définitions de priorité du projet placent les tâches à haute priorité sur une échelle de quelques heures à quelques jours, à accomplir dès que possible. Les tâches à faible priorité sont prévues pour le prochain cycle de mise à jour régulier, avec deux semaines comme exemple.
Choisissez votre configuration de phare
Mettez à jour le nœud de balise rapidement. La mise à jour du client de validateur a une faible priorité et fait partie du cycle habituel.
Les nœuds balises avec et sans staking sont une priorité élevée ; les clients validateurs avec staking peuvent utiliser le cycle de mise à jour habituel.
Les mécanismes de vulnérabilité et leur impact potentiel restent non divulgués. Une priorité élevée indique l'urgence de la mise à niveau. Les heures ou jours et deux semaines sont des indications de catégorie illustratives, non des échéances fixes. Aucune date de publication de l'avis n'est fournie.
Les maintaineurs indiquent que la v8.3.3 n'introduit aucune modification cassante, mais recommandent néanmoins aux utilisateurs qui mettent à niveau depuis la v8.2.x ou une version antérieure de consulter les notes de version de la v8.3.0, un point supplémentaire à prendre en compte pour les opérateurs ayant sauté les versions intermédiaires.
Les détails de la vulnérabilité du client Ethereum suivront
La publication indique que les détails techniques des vulnérabilités seront divulgués ultérieurement. Les liens vers les avis de sécurité seront ajoutés une fois que les opérateurs de réseau auront eu le temps de mettre à jour leurs systèmes.
Cette approche suit l'explication du processus de divulgation de Sigma Prime du 5 novembre. Le développeur de Lighthouse indique qu'il retient initialement les informations sur les vulnérabilités pour donner aux utilisateurs le temps de mettre à jour leurs nœuds, puis ajoute les détails aux notes de version et aux avis de sécurité GitHub.
L'avis v8.3.3 ne signale aucune exploitation active ni perte identifiée, et les mécanismes d'attaque ainsi que leur impact potentiel restent non divulgués. La mention « haute priorité » ne révèle ni la gravité technique ni les conséquences d'une attaque.
La demande concerne spécifiquement le logiciel beacon-node de Lighthouse. Pour les opérateurs exécutant les deux composants Lighthouse, effectuer une mise à jour du client de validateur seul laisserait toujours l'instruction du beacon-node en attente.
Vérifier quel composant est en cours de mise à niveau est essentiel, car les deux entrées du tableau de publication ont des calendriers différents. Les détails retenus rendent également les allégations de vol ou d'arrêt imminant de la chaîne non étayées par cet avis.