Desenvolvedores da EthereumPoS, encontraram um bug que poderia colocar em risco toda a chain EVM por excesso de cobrança de gás

Os desenvolvedores do EthereumPoS identificaram um bug no cliente Besu EthereumPoS que poderia ter levado à “falha de consenso em redes com várias implementações de EVM”, conforme divulgado por CryptoSlate.

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 possui transações que desencadeariam essa falha”.

Bug identificado durante a revisão do código The Merge

Swende documentou que encontrou o bug enquanto “fazia alguns fuzzing #ethereumPoS em preparação para TheMerge”. Em resposta a um jornalista da CryptoSlate, Swende afirmou que os usuários que executam um nó Besu ficariam presos e “não conseguiriam seguir a canon chain”. Além disso, qualquer “rede dominada por besu poderia ter sido interrompida”.

They would have been stuck, not able to follow the canon chain. And/or, any besu-dominated network (non-eth-mainnet) could have been stopped in it's tracks.

— M H (((Swende))) (@mhswende) September 27, 2022

O cliente Besu é o segundo cliente mais popular na rede EthereumPoS, atrás do Geth. De acordo com dados disponíveis via ethernodes.org, o cliente Besu é usado por 7,81% dos clientes da rede principal Ethereum.

Versões vulneráveis ​​do cliente Besu

A versão 22.7.1 do cliente Besu contém uma correção para garantir que “o excesso de gás não seja alocado para chamadas de transações internas e corrigindo os erros de excesso de gás”.

As versões anteriores a 22.1.3 também “impedem a execução incorreta”, no entanto, a rede principal Ethereum requer outros recursos disponíveis apenas em versões posteriores. As versões do cliente 22.4.0 a 22.7.0 são atualmente consideradas vulneráveis ​​ao bug do gás.

Como resultado, os usuários do cliente Besu na rede principal devem atualizar para a versão corrigida.

Impacto e resolução

Danno Ferrin criou um artigo completo sobre o assunto, publicado em 21 de setembro. A análise de Ferrin afirmou que:

Uma falha no tratamento de dados não assinados como dados assinados, um contrato inteligente codificado corretamente pode criar uma chamada de função que retornará mais gás do que foi passado.

• Veja também: Ethereum, Validadores e a Descentralização em risco

Mais 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 nenhum problema na rede principal Ethereum. Para um mau ator explorar maliciosamente o bug, ele teria que agir de maneira precisa.

Para elevar isso a um bug que interrompe a chain, foi necessária uma chamada deliberadamente criada, envolvendo algumas interações com a regra EIP-150 todos menos um 64º e reservando uma parte do gás disponível para o contrato de chamada.

Se o bug não fosse encontrado, qualquer chain com alta participação do cliente Besu poderia ter experimentado um “loop infinito” de contrato inteligente, pelo qual o contrato seria “realmente executado para sempre”.

Ferrin afirmou que o fuzzing permitiu que os desenvolvedores identificassem e corrigissem o bug sem problemas. Fuzzing é um método usado por desenvolvedores de software “que envolve o fornecimento de dados inválidos, inesperados ou aleatórios como entradas para um programa de computador”.

• Veja também: LUNC aguarda o julgamento da Binance quanto a queima das taxas de transações

A maior lição demonstrada por esse exploit é que a comparação de dados de rastreamento em uma execução fuzzing detecta mais bugs do que simplesmente comparar os resultados finais.

O bug do excesso de gás tornou-se um não-evento devido à diligência dos desenvolvedores do Ethereum que se dedicam a proteger a rede. No entanto, o dano potencial que poderia ter causado mostra a complexidade por trás da execução da mesclagem sem problemas.

O bug foi corrigido na versão 22.7.1 usando “ um método de conversão diferente que “fixará” os valores de estouro aos valores máximos esperados, evitando os problemas de tradução assinada”. Ferrin comentou que os usuários que executam nós dentro do intervalo vulnerável devem atualizar para a versão mais recente.