Gli sviluppatori di Ethereum hanno scoperto un bug che potrebbe portare al blocco delle catene EVM a causa di un errore di eccesso di gas nel client Besu.
Gli sviluppatori di Ethereum hanno individuato un bug all’interno del client Besu di Ethereum che potrebbe portare al “fallimento del consenso nelle reti con più implementazioni EVM”.
Gary Schulte ha segnalato il problema al repository GitHub di Hyperledger ed è stato trovato da Martin Holst Swende. A quanto risulta, “nessuna rete di produzione ha transazioni che potrebbero innescare questo fallimento”.
Bug identificato durante la revisione del codice di The Merge
Swende ha documentato di aver trovato il bug mentre “faceva un po’ di fuzzing su TheMerge”. In risposta al nostro giornalista, Swende ha dichiarato che gli utenti che utilizzano un nodo Besu si sarebbero bloccati e “non sarebbero stati in grado di seguire la catena del canone”. Inoltre, qualsiasi “rete dominata da Besu avrebbe potuto essere bloccata”.
Sarebbero stati bloccati, non in grado di seguire la catena canonica. E/o, qualsiasi rete dominata da besu (non eth-mainnet) avrebbe potuto essere bloccata.
– M H (((Swende)) (@mhswende) September 27, 2022
Il client Besu è il secondo client più popolare sulla rete Ethereum, dopo Geth. Secondo i dati disponibili su ethernodes.org, il client Besu è utilizzato dal 7,81% dei clienti della mainnet di Ethereum.
Versioni vulnerabili del client Besu
La versione 22.7.1 del client Besu contiene una correzione per garantire che “il gas in eccesso non venga allocato per le chiamate alle transazioni interne e per correggere gli errori di eccesso di gas”.
Anche le versioni precedenti alla 22.1.3 “prevengono le esecuzioni errate”, tuttavia Ethereum mainnet richiede altre funzionalità disponibili solo nelle versioni successive. Le versioni del client dalla 22.4.0 alla 22.7.0 sono attualmente considerate vulnerabili al bug del gas.
Di conseguenza, gli utenti del client Besu sulla mainnet devono aggiornare alla versione patchata.
Impatto e risoluzione
Danno Ferrin ha creato un’analisi completa del problema in un articolo di Hackmd pubblicato il 21 settembre. L’analisi di Ferrin afferma che
“Una falla nella gestione dei dati non firmati come dati firmati, uno smart contract codificato correttamente può creare una chiamata di funzione che restituisce più gas di quanto sia stato passato “
Ulteriori informazioni tecniche sul bug sono disponibili nel post di Ferrin. Tuttavia, l’aspetto principale è che il bug è stato risolto senza alcun problema sulla mainnet di Ethereum. Per sfruttare il bug in modo malevolo, un malintenzionato avrebbe dovuto agire in modo preciso.
“Per elevare questo bug a un bug di chain-halting è stata necessaria una chiamata deliberatamente realizzata, che ha comportato alcune interazioni con la regola EIP-150 “all but one 64th” e la riserva di una parte del gas disponibile per il contratto chiamante. “
Se il bug non fosse stato individuato, qualsiasi catena con un’elevata partecipazione da parte del cliente Besu avrebbe potuto sperimentare un “loop infinito” dello smart contract, in cui il contratto sarebbe stato “veramente eseguito per sempre”.
Ferrin ha dichiarato che il fuzzing ha permesso agli sviluppatori di identificare e correggere il bug senza problemi. Il fuzzing è un metodo utilizzato dagli sviluppatori di software “che consiste nel fornire dati non validi, inaspettati o casuali come input a un programma informatico”.
“La più grande lezione dimostrata da questo exploit è che il confronto dei dati di traccia in un’esecuzione di fuzzing cattura più bug rispetto al semplice confronto dei risultati finali. “
Il bug dell’eccesso di gas è diventato un non evento grazie alla diligenza degli sviluppatori di Ethereum che si sono dedicati alla protezione della rete. Tuttavia, il danno potenziale che avrebbe potuto causare dimostra la complessità dell’esecuzione del merge senza problemi.
Il bug è stato corretto nella versione 22.7.1 utilizzando “un metodo di conversione diverso che “blocca” i valori di overflow ai valori massimi previsti evitando i problemi di traduzione firmata”. Ferrin ha commentato che gli utenti che eseguono nodi all’interno dell’intervallo di vulnerabilità dovrebbero aggiornare alla versione più recente.
