Les développeurs d'Ethereum ont fusionné un correctif pour une faille de traitement des dépôts dans la prochaine mise à jour Glamsterdam qui aurait pu permettre à un constructeur de blocs de recevoir des ETH destinés à un nouveau validateur, après une décision initiale de rejeter la modification proposée.
Résumé
- Ethereum a fusionné un correctif de traitement des dépôts de Glamsterdam le 26 octobre.
- La faille aurait pu créditer les dépôts de staking aux constructeurs partageant la même clé publique.
- Les développeurs ont d'abord rejeté la correction avant d'approuver des tests supplémentaires.
- Une enquête distincte sur la compatibilité des contrats a retardé l'activation de Hoodi de Glamsterdam.
Selon les spécifications de consensus d'Ethereum, le mainteneur Justin Traglia a fusionné la correction le 26 octobre après que le développeur avsetsin a identifié un problème dans la façon dont les dépôts en attente seraient traités lors du fork Gloas. La modification sépare les dépôts des constructeurs des dépôts des validateurs en fonction de leurs identifiants de retrait, empêchant les fonds d'entrer dans le mauvais compte lorsque les deux utilisent la même clé publique.
La vulnérabilité concernait des règles en cours de développement, et non un vol confirmé sur le réseau principal d'Ethereum. Les développeurs ont intégré la correction dans les spécifications, bien que les clients de consensus individuels doivent encore implémenter et tester le comportement révisé.
La faille de Glamsterdam d'Ethereum exposait un risque pour les dépôts des validateurs
Le problème est apparu à partir des changements prévus dans le cadre de la séparation proposant-constructeur inscrite dans Glamsterdam, qui attribue la construction des blocs et la proposition des blocs à des rôles différents. Les constructeurs assemblent les charges utiles de transaction, tandis que les validateurs participent à la proposition et à la confirmation des blocs via le système de preuve d'enjeu d'Ethereum.
Le chercheur avsetsin a décrit la faille le 12 octobre, identifiant un problème dans les règles utilisées pour traiter les dépôts en attente lors de la mise à niveau du réseau. Si un constructeur s'enregistrait à l'aide d'une clé publique avant qu'un dépôt de validateur n'arrive sous la même clé, la logique proposée pourrait créditer les deux dépôts au constructeur.
Le chercheur a décrit un scénario impliquant un opérateur de staking recevant des fonds d'un protocole de staking liquide pour établir un nouveau validateur. En s'enregistrant d'abord comme constructeur, l'opérateur pourrait faire entrer le dépôt de validateur du protocole dans le solde du constructeur, où l'adresse de retrait pourrait être sous le contrôle de l'opérateur.
« L'opérateur peut retirer les fonds du protocole », a averti avsetsin dans le rapport GitHub.
Comme le validateur attendu ne serait pas créé, le service de staking pourrait avoir du mal à obtenir la preuve nécessaire pour mener à bien ses procédures normales de dépôt et de récupération.
Le chercheur a examiné l'exposition potentielle impliquant Lido, Origin et Rocket Pool au moyen d'une recherche préliminaire sur le code. Ces conclusions étaient conditionnées par la manière dont les protocoles individuels géraient les dépôts, et le rapport n'a pas établi que les projets avaient subi une exploitation.
Les développeurs reviennent sur leur décision après un examen plus approfondi
La correction proposée a d'abord rencontré une résistance de la part des développeurs de clients Ethereum, malgré la description par le chercheur du risque de routage des dépôts. Le 19 octobre, Traglia a fermé la demande de tirage après des discussions entre les développeurs principaux.
« Il n'y avait pas assez de soutien de la part des clients pour effectuer ce changement pour le moment », a écrit Traglia.
La décision n'est pas restée en place, les développeurs ayant rouvert la proposition le 23 octobre après un examen plus approfondi.
Par la suite, le réviseur potuz a approuvé l'approche mais a demandé davantage de tests pour des combinaisons de dépôts spécifiques. Avsetsin a ajouté ces tests le 23 octobre, couvrant les cas où les dépôts de constructeur et de validateur partagent une clé publique mais nécessitent un traitement séparé.
La modification finale a été fusionnée dans les spécifications de consensus d'Ethereum le 26 octobre après un examen supplémentaire des clients. Elle dirige les dépôts de validateurs valides vers la file d'attente des validateurs tout en permettant aux dépôts légitimes de constructeurs d'enregistrer ou d'ajouter des fonds à un constructeur existant.
Les nouvelles règles distinguent les dépôts au moyen des identifiants de retrait, qui déterminent les modalités de retrait autorisées. Elles préservent des enregistrements distincts pour les constructeurs et les validateurs, même lorsque la même clé publique apparaît dans les deux rôles.
Le retard de Hoodi donne aux développeurs plus de temps pour enquêter
La mise à jour de la spécification est arrivée alors que les développeurs d'Ethereum examinaient un problème distinct affectant l'activation prévue de Glamsterdam sur le testnet Hoodi. La Fondation Ethereum a reporté la mise à niveau du 26 octobre après que les chercheurs ont identifié des risques de compatibilité impliquant l'EIP-8037.
Comme crypto.news l'a précédemment rapporté concernant le report, la décision a retiré à la fois les changements d'exécution d'Amsterdam et les changements de consensus de Gloas de l'activation prévue de Hoodi. L'augmentation proposée à une limite de 200 millions de gaz a été reportée avec eux.
Le chercheur d'Ethereum Toni Wahrstätter a expliqué que l'EIP-8037 pourrait interférer avec les contrats intelligents qui reposent sur des hypothèses concernant le gaz restant pendant l'exécution. Il a identifié des cas où la comptabilisation du gaz pourrait amener une transaction à être annulée de manière inattendue ou permettre un chemin d'exécution que les développeurs pensaient inatteignable.
Le problème de compatibilité des contrats est distinct du défaut de dépôt des constructeurs corrigé dans la correction GitHub. Les deux concernent Glamsterdam, mais le report du 22 octobre de la Fondation a spécifiquement cité l'investigation plus approfondie de l'interaction de l'EIP-8037 avec les contrats existants.
Les clients Ethereum doivent mettre en œuvre les règles révisées
Glamsterdam a déjà été activé sur le testnet Sepolia le 6 octobre, où les développeurs ont examiné les changements de construction des blocs et une capacité de traitement des transactions plus élevée. La répétition ultérieure sur Hoodi reste non planifiée, sans date confirmée pour l'activation sur le réseau principal d'Ethereum.
La correction fusionnée des dépôts contient des tests de régression couvrant la manière dont les dépôts sont classifiés pendant la transition Gloas. Les équipes clientes doivent intégrer le changement de spécification dans leur logiciel et effectuer des tests supplémentaires avant que les règles mises à jour puissent fonctionner lors d'une future mise à niveau du réseau.
