L'un des clients de consensus d'Ethereum a fusionné un correctif pour une attaque d'empoisonnement du cache de clés publiques de validateurs, selon une pull request sur GitHub. Le patch corrige une vulnérabilité autour du fork Gloas, qui pourrait entraîner le rejet par certains nœuds de signatures valides en raison d'un bug dans le cache global de clés publiques.
Gloas est la partie de la couche de consensus de la prochaine mise à niveau Glamsterdam.
Trois dépôts, deux chaînes
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 donner les mêmes validateurs sur chaque chaîne, bien que ce soit une autre histoire à la frontière du fork.
L'attaquant a besoin de 3 dépôts en attente juste avant le fork. Le premier est un important rechargement pour un validateur existant. Les deux autres sont de nouvelles clés : A avec des identifiants de builder et B avec des identifiants de validateur réguliers.
Sur la chaîne canonique, le rechargement consomme le churn de solde, de sorte que A et B sont traités après le fork. A devient un builder, et B prend l'index de validateur suivant.
Sur la chaîne latérale de l'attaquant, le validateur rechargé est slashed 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 et se sépareraient.
En réalité, l'attaque est quelque peu compliquée, car elle nécessite un slashing au bon moment et une chaîne latérale, il est donc peu probable qu'elle se produise par accident.
Que change le correctif ?
Selon la PR, le correctif consiste à n'ajouter les clés au cache global de clés publiques qu'une fois leur époque d'éligibilité à l'activation 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 ont eu un problème similaire. En d'autres termes, plus Glamsterdam approche, plus les développeurs doivent attraper de cas limites autour de la frontière du fork.
