Satoshi BrotherTon frère sur le marché crypto
FR

Un Bug Majeur d'Ethereum (ETH) Pourrait Enfin Être Corrigé - U.Today

Le dernier correctif d'Ethereum traite d'un bug critique du cache de clés publiques des validateurs, renforçant la sécurité avant la mise à niveau Glamsterdam et atténuant les attaques potentielles.

Un Bug Majeur d'Ethereum (ETH) Pourrait Enfin Être Corrigé - U.Today

Correctif pour une vulnérabilité dans Ethereum

Un des clients de consensus d'Ethereum a intégré un correctif pour une vulnérabilité liée à une attaque de contamination du cache de clés publiques des validateurs, selon une demande de tirage sur GitHub. Ce patch aborde une faille autour du fork Gloas, qui pourrait entraîner le rejet de signatures valides par certains nœuds en raison d'un bug dans le cache global des clés publiques. Gloas fait partie de la couche de consensus de la prochaine mise à niveau Glamsterdam.

Mécanisme de vulnérabilité

Le problème réside dans un mécanisme où le client stocke les clés publiques des validateurs et leurs index dans un cache global. Techniquement, les dépôts déjà finalisés devraient fournir les mêmes validateurs sur chaque chaîne, bien que la situation soit différente à la frontière du fork. L'attaquant a besoin de trois dépôts en attente juste avant le fork. Le premier est un important complément pour un validateur existant, tandis que les deux autres sont de nouvelles clés : A, avec des identifiants de constructeur, et B, avec des identifiants de validateur réguliers.

Sur la chaîne canonique, le complément consomme le changement de solde, donc A et B sont traités après le fork. A devient un constructeur, et B prend le prochain index de validateur.

Impact de l'attaque

Du côté de la chaîne de l'attaquant, le validateur complété est sanctionné avant le fork, et son dépôt est ignoré. Cela conduit à ce que A soit traité plus tôt, prenant essentiellement l'index de B. Le cache défectueux supposait que les deux chaînes produiraient les mêmes validateurs et importait la clé de A globalement. Au moment du fork, les nœuds affectés rejetteraient toutes les signatures valides de B sur la chaîne canonique, entraînant une séparation.

En réalité, l'attaque est quelque peu complexe, car elle nécessite une sanction au bon moment et une chaîne secondaire, ce qui rend peu probable qu'elle se produise par accident.

Le correctif proposé

Selon la demande de tirage, le correctif consiste à n'ajouter des clés au cache global de clés publiques qu'une fois que leur époque d'éligibilité à l'activation est finalisée. Une nouvelle structure, HeadPubkeys, combine également les clés de l'état de tête et du cache global, afin que les nœuds ne manquent pas de clés si la chaîne se finalise sans nouveaux blocs.

Il reste à confirmer si d'autres clients de consensus avaient un problème similaire. En d'autres termes, plus la mise à niveau Glamsterdam se rapproche, plus les cas particuliers autour de la frontière du fork que les développeurs doivent gérer sont nombreux.

Dans d’autres langues: EnglishРусскийDeutschItalianoEspañol

Charte éditoriale et IA · Contact