Correction de la faille de gestion des dépôts dans Ethereum
Les développeurs d’Ethereum ont intégré un correctif pour une faille de gestion des dépôts dans la prochaine mise à niveau Glamsterdam. Cette faille aurait pu permettre à un constructeur de bloc de recevoir des ETH destinés à un nouveau validateur, suite à une décision initiale de rejeter le changement proposé. 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 concernant la manière dont les dépôts en attente seraient traités lors du fork Gloas.
Le changement sépare les dépôts des constructeurs de ceux des validateurs en fonction de leurs informations de retrait, empêchant ainsi 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 mainnet d’Ethereum. Les développeurs ont intégré la correction dans les spécifications, bien que les clients de consensus individuels doivent encore mettre en œuvre et tester le comportement révisé.
Origine et description de la faille
Le problème est apparu à partir des changements prévus dans la séparation des proposeurs et des constructeurs inscrite dans Glamsterdam, qui attribue la construction de blocs et la proposition de blocs à différents rôles. Les constructeurs assemblent des charges utiles de transactions, 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 des mises à niveau du réseau. Si un constructeur s’inscrit en utilisant 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’inscrivant d’abord en tant que constructeur, l’opérateur pourrait faire en sorte que le dépôt de validateur du protocole entre 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 son rapport sur GitHub.
Réactions et mise à jour des spécifications
Le chercheur a examiné l’exposition potentielle impliquant Lido, Origin et Rocket Pool à travers une recherche préliminaire de code. Ces résultats étaient conditionnels à 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. La correction proposée a initialement 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 parmi les développeurs principaux. « Il n’y avait pas assez de soutien de la part des clients pour apporter ce changement à ce 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é plus 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 des constructeurs et des validateurs partagent une clé publique mais nécessitent un traitement séparé.
Le changement final a été fusionné dans les spécifications de consensus d’Ethereum le 26 octobre après un examen supplémentaire des clients. Il dirige les dépôts de validateurs valides vers la file d’attente des validateurs tout en permettant aux dépôts de constructeurs légitimes de s’inscrire ou d’ajouter des fonds à un constructeur existant.
Problèmes de compatibilité et mise à jour de Glamsterdam
La mise à jour des spécifications 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 des chercheurs ont identifié des risques de compatibilité impliquant l’EIP-8037.
Le chercheur d’Ethereum Toni Wahrstätter a expliqué que l’EIP-8037 pourrait interférer avec des contrats intelligents reposant sur des hypothèses concernant le gaz restant pendant l’exécution. Il a identifié des cas où la comptabilité du gaz pourrait provoquer un retour inattendu d’une transaction ou permettre un chemin d’exécution que les développeurs avaient supposé inaccessibles.
Le problème de compatibilité des contrats est distinct de la faille de dépôt des constructeurs abordée dans la correction GitHub. Les deux concernent Glamsterdam, mais le report du 22 octobre de la Fondation a spécifiquement cité un examen plus approfondi de l’interaction de l’EIP-8037 avec les contrats existants.
Glamsterdam a déjà été activé sur le testnet Sepolia le 6 octobre, où les développeurs ont examiné les changements de construction de blocs et une capacité de traitement des transactions plus élevée. La répétition suivante de Hoodi reste non programmée, sans date confirmée pour l’activation sur le mainnet d’Ethereum.
La correction de dépôt fusionnée contient des tests de régression couvrant la manière dont les dépôts sont classés pendant la transition Gloas. Les équipes de clients doivent intégrer le changement de spécification dans leur logiciel et compléter d’autres tests avant que les règles mises à jour puissent fonctionner lors d’une future mise à niveau du réseau.
