Ethereum developers discovered a bug that could lead to EVM chains becoming stuck due to an excess gas error in the Besu client.
Ethereum developers discovered a bug that could lead to EVM chains becoming stuck due to an excess gas error in the Besu client.
Ethereum developers identified a bug within the Besu Ethereum client that could have led to “consensus failure in networks with multiple EVM implementations”.
Gary Schulte relatou o problema ao repositório Hyperledger GitHub e foi encontrado por Martin Holst Swende. Entende-se que “nenhuma rede de produção tem transacções que possam desencadear esta falha”
Bug identificado durante a revisão do código da Merge
Swende documentou que encontrou o insecto enquanto “fazia algumas TheMerge”. Em resposta ao nosso jornalista, Swende declarou que os utilizadores a correr um nó Besu teriam ficado presos e “não seriam capazes de seguir a cadeia canónica”. Além disso, qualquer “rede dominada por Besu poderia ter sido parada nos seus rastos”.
Teriam ficado presos, não conseguindo seguir a cadeia canónica. E/ou, qualquer rede besu-dominada (não rede principal) poderia ter sido parada nas suas pistas.
– M H ((((Swende))) (@mhswende) 27 de Setembro de 2022
W
O cliente Besu é o segundo cliente mais popular da rede Ethereum atrás de Geth. De acordo com dados disponíveis via ethernodes.org, o cliente Besu é utilizado por 7,81% dos clientes da rede principal Ethereum.
Vulnerável versões cliente Besu
Version 22.7.1 do cliente Besu contém uma correcção para assegurar que “o excesso de gás não será atribuído a chamadas de transacções internas e a correcção dos erros de gás em excesso”.
As versões anteriores à 22.1.3 também “evitarão a execução incorrecta”, no entanto, a rede principal Ethereum requer outras características disponíveis apenas em versões posteriores. As versões clientes 22.4.0 a 22.7.0 são actualmente consideradas vulneráveis ao bug do gás.
Como resultado, os utilizadores do cliente Besu na rede principal devem actualizar para a versão corrigida.
Impacto e resolução
Danno Ferrin criou uma redacção completa da edição num artigo da Hackmd publicado a 21 de Setembro. A análise da Ferrin afirmava que
“Uma falha no tratamento de dados não assinados como dados assinados um contrato inteligente devidamente codificado pode criar uma chamada de função que devolverá mais gás do que aquele em que foi passado”.
Outras informações técnicas sobre o bug podem ser encontradas no post de Ferrin. No entanto, a principal conclusão é que o bug foi resolvido sem qualquer problema na rede principal Ethereum. Para um mau actor explorar maliciosamente o bug, eles teriam de agir de uma forma precisa.
“A fim de elevar isto a um bug em cadeia, foi necessária uma chamada deliberadamente criada, envolvendo algumas interacções com a regra EIP-150 “all but one 64th” e reservando uma porção de gás disponível para o contrato de chamada.”
Se o bug não fosse encontrado, qualquer cadeia com alta participação do cliente Besu poderia ter experimentado um contrato inteligente “loop infinito”, pelo qual o contrato “executaria verdadeiramente para sempre”.
Ferrin afirmou que o fuzzing permitiu aos criadores identificar e corrigir o bug sem problemas. O fuzzing é um método utilizado pelos programadores de software “que envolve o fornecimento de dados inválidos, inesperados, ou aleatórios como entradas para um programa de computador”
“A maior lição demonstrada por esta exploração é que a comparação de dados de rastreio numa execução de fuzzing apanha mais bugs do que a simples comparação dos resultados finais”.
O excesso de gás tornou-se um não-evento devido à diligência dos criadores de Ethereum que se dedicaram à protecção da rede. Contudo, os danos potenciais que poderia ter causado mostram a complexidade por detrás da execução da fusão sem problemas.
O bug foi corrigido na versão 22.7.1 utilizando “um método de conversão diferente que “fixará” os valores de transbordo para os valores máximos esperados, evitando os problemas de tradução assinados”. Ferrin comentou que os utilizadores que executam nós dentro da gama vulnerável devem actualizar para a versão mais recente.
