Les développeurs d’Ethereum ont découvert un bug qui pouvait conduire à des chaînes EVM bloquées en raison d’une erreur d’excès de gaz dans le client Besu.
Les développeurs d’Ethereum ont identifié un bug au sein du client Besu Ethereum qui aurait pu conduire à « l’échec du consensus dans les réseaux avec plusieurs implémentations EVM. »
Gary Schulte a signalé le problème au dépôt Hyperledger GitHub et a été trouvé par Martin Holst Swende. Il est entendu qu' »aucun réseau de production n’a de transactions qui pourraient déclencher cet échec ».
Bug identifié lors de la revue de code de The Merge
Swende a indiqué qu’il avait trouvé le bogue en « faisant un peu de fuzzing TheMerge ». En réponse ànotre journaliste, Swende a déclaré que les utilisateurs exécutant un nœud Besu seraient restés bloqués et « incapables de suivre la chaîne de canon ». De plus, tout « réseau dominé par Besu aurait pu être stoppé dans son élan. «
Ils auraient été bloqués, incapables de suivre la chaîne des canons. Et/ou, tout réseau dominé par les besu (non-eth-mainnet) aurait pu être stoppé dans son élan.
– M H (((Swende))) (@mhswende) September 27, 2022
Le client Besu est le deuxième client le plus populaire sur le réseau Ethereum, derrière Geth. Selon les données disponibles sur ethernodes.org, le client Besu est utilisé par 7,81 % des clients du réseau principal Ethereum.
Versions vulnérables du client Besu
La version 22.7.1 du client Besu contient un correctif pour s’assurer que « l’excès de gaz ne sera pas alloué aux appels de transactions internes et corriger les erreurs d’excès de gaz. »
Les versions antérieures à 22.1.3 permettront également « d’éviter les erreurs d’exécution ». Cependant, le réseau principal Ethereum requiert d’autres fonctionnalités disponibles uniquement dans les versions ultérieures. Les versions 22.4.0 à 22.7.0 du client sont actuellement considérées comme vulnérables au bug du gaz.
Par conséquent, les utilisateurs du client Besu sur le réseau principal doivent passer à la version corrigée.
Impact et résolution
Danno Ferrin a rédigé un article complet sur le problème dans un article de Hackmd publié le 21 septembre. L’analyse de Ferrin indique que
« Une faille dans le traitement des données non signées comme des données signées, un contrat intelligent correctement codé peut créer un appel de fonction qui renverra plus de gaz que ce qui a été passé. «
Des informations techniques supplémentaires concernant le bogue peuvent être trouvées dans le post de Ferrin. Cependant, l’essentiel est que le bogue a été résolu sans aucun problème sur le réseau principal d’Ethereum. Pour qu’un mauvais acteur puisse exploiter le bug de manière malveillante, il aurait fallu qu’il agisse de manière précise.
« Afin d’élever ce bogue au rang de bogue de blocage de chaîne, un appel délibérément conçu était nécessaire, impliquant quelques interactions avec la règle EIP-150 « all but one 64th » et réservant une partie du gaz disponible pour le contrat appelant. «
Si le bogue n’avait pas été trouvé, toute chaîne avec une forte participation du client Besu aurait pu connaître une « boucle infinie » de contrat intelligent dans laquelle le contrat aurait « vraiment exécuté pour toujours ».
Ferrin a déclaré que le fuzzing a permis aux développeurs d’identifier et de corriger le bug sans problème. Le fuzzing est une méthode utilisée par les développeurs de logiciels « qui consiste à fournir des données non valides, inattendues ou aléatoires en entrée d’un programme informatique »
« La plus grande leçon démontrée par cet exploit est que la comparaison des données de trace dans une exécution de fuzzing attrape plus de bogues que la simple comparaison des résultats finaux. «
Le bug de l’excès de gaz est devenu un non-événement grâce à la diligence des développeurs d’Ethereum qui se sont consacrés à la protection du réseau. Cependant, les dommages potentiels qu’il aurait pu causer montrent la complexité de l’exécution de la fusion sans problème.
Le bogue a été corrigé dans la version 22.7.1 en utilisant « une méthode de conversion différente qui « serre » les valeurs de dépassement aux valeurs maximales attendues, évitant ainsi les problèmes de traduction signée. » Ferrin a indiqué que les utilisateurs qui exécutent des nœuds dans la plage de vulnérabilité doivent mettre à jour la version la plus récente.
