Los desarrolladores de Ethereum descubrieron un fallo que podía llevar a que las cadenas de EVM se atascaran debido a un error de exceso de gas en el cliente Besu.
Los desarrolladores de Ethereum identificaron un error dentro del cliente de Besu Ethereum que podría haber llevado a un «fallo de consenso en redes con múltiples implementaciones de EVM».
Gary Schulte informó del problema en el repositorio GitHub de Hyperledger y fue encontrado por Martin Holst Swende. Se entiende que «ninguna red de producción tiene transacciones que desencadenen este fallo».
Fallo identificado durante la revisión del código de The Merge
Swende documentó que encontró el fallo mientras «hacía algo de fuzzing en TheMerge». En respuesta anuestro periodista, Swende declaró que los usuarios que ejecutan un nodo Besu se habrían quedado atascados y «no podrían seguir la cadena de canon». Además, cualquier «red dominada por Besu podría haberse detenido en su camino».
Se habrían quedado atascados, sin poder seguir la cadena del canon. Y/o, cualquier red dominada por besu (no eth-mainnet) podría haber sido detenida en su camino.
– M H (((Swende))) (@mhswende) September 27, 2022
El cliente Besu es el segundo más popular en la red Ethereum, por detrás de Geth. Según los datos disponibles en ethernodes.org, el cliente Besu es utilizado por el 7,81% de los clientes de la red principal de Ethereum.
Versiones vulnerables del cliente Besu
La versión 22.7.1 del cliente Besu contiene una corrección para garantizar que «el exceso de gas no se asigne a las llamadas de transacciones internas y corregir los errores de exceso de gas».
Las versiones anteriores a la 22.1.3 también «evitarán la ejecución incorrecta», sin embargo, Ethereum mainnet requiere otras características sólo disponibles en versiones posteriores. Las versiones del cliente 22.4.0 a 22.7.0 se consideran actualmente vulnerables al error de gas.
Como resultado, los usuarios del cliente Besu en la mainnet deben actualizar a la versión parcheada.
Impacto y resolución
Danno Ferrin elaboró un completo informe sobre el problema en un artículo de Hackmd publicado el 21 de septiembre. El análisis de Ferrin afirmaba que
«Un fallo en el manejo de datos sin firmar como datos firmados un contrato inteligente codificado correctamente puede crear una llamada a una función que devolverá más gas del que se pasó».
En el post de Ferrin se puede encontrar más información técnica sobre el fallo. Sin embargo, lo principal es que el fallo se resolvió sin ningún problema en la red principal de Ethereum. Para que un mal actor explotara el fallo de forma maliciosa, tendría que haber actuado de forma precisa.
«Para que esto se convierta en un fallo de salto de cadena, se necesitaba una llamada deliberadamente elaborada, que implicara algunas interacciones con la regla de «todos los 64 menos uno» de EIP-150 y que reservara una porción de gas disponible para el contrato de llamada. «
Si no se encontraba el fallo, cualquier cadena con alta participación del cliente de Besu podría haber experimentado un «bucle infinito» de contrato inteligente por el que el contrato «se ejecutaría realmente para siempre».
Ferrin declaró que el fuzzing permitió a los desarrolladores identificar y parchear el fallo sin problemas. El fuzzing es un método utilizado por los desarrolladores de software «que consiste en proporcionar datos no válidos, inesperados o aleatorios como entradas a un programa informático»
«La mayor lección demostrada por este exploit es que la comparación de los datos de rastreo en una ejecución de fuzzing detecta más errores que la simple comparación de los resultados finales. «
El fallo de exceso de gas se convirtió en un no evento debido a la diligencia de los desarrolladores de Ethereum que se dedicaron a proteger la red. Sin embargo, el daño potencial que podría haber causado pone de manifiesto la complejidad de ejecutar la fusión sin problemas.
El fallo fue parcheado en la versión 22.7.1 utilizando «un método de conversión diferente que «sujetará» los valores de desbordamiento a los valores máximos esperados evitando los problemas de traducción firmada». Ferrin comentó que los usuarios que ejecutan nodos dentro del rango vulnerable deberían actualizar a la versión más reciente.
