Analisi di un uno Smart Contract: BatchOverflow, come evitarlo?

Nelle ultime ore la comunità Ethereum e delle Cryptocurrencies in generale è scossa dall'ultimo bug scovato in un token ERC20, a cui è stato assegnato il nome di BatchOverflow. Ma come funziona questo bug? Come risolverlo?

Nelle nostre guide di sviluppo di Smart Contracts non smettiamo mai di ripeterlo: scrivere Smart Contracts non è come scrivere codice "vecchio stile". Quando scriviamo uno Smart Contract andiamo a gestire flussi di denaro, attraverso un software che una volta caricato su Blockchain non può essere cambiato o bloccato (se non con specifici pattern).

BatchOverflow, una moltiplicazione fatale!

Esatto, BatchOverflow nasce da un un overflow in una variabile di tipo Integer! Se non conosci il significato della parola overflow non ti preoccupare, è molto semplice da capire con un esempio: abbiamo una variabile di tipo uint256, che può memorizzare fino a 256 bit. Se dovessimo provare a salvare un dato più grande ci troveremmo con un Overflow, che porta la variabile al valore 0!

Questo tipo di vulnerabilità è stato trovato grazie a due transazioni di altissimo valore del Token BEC (BeautyChain), più precisamente nella funzione batchTransfer.

La funzione incriminata

La funzione batchTransfer ha lo scopo di inviare una certa quantità di token ad un insieme di indirizzi Ethereum. Possiamo infatti vedere i parametri della funzione _receivers (un vettore di address) e la quantità _value di tipo uint256.

Alla riga 257 troviamo amount, una variabile di tipo uint256 a cui viene assegnato il risultato della moltiplicazione tra il numero di indirizzi a cui inviare il token e il valore da inviare a ciascuno.

Questa operazione dovrebbe calcolare quindi il totale in ETH da inviare agli indirizzi. Peccato però che passando alla funzione batchTransfer due indirizzi Ethereum (o comunque un numero compreso tra 0 e 20 per soddisfare la condizione alla riga 257) e moltiplicandola per un numero molto grande come variabile _value il risultato sarà davvero troppo grande per essere salvato in 256bit, portando amount a 0 (zero!).

Con la variabile cnt a 2 e amount a 0 possiamo soddisfare il require alla riga 258 e 259, in quanto il balance dell'indirizzo deve essere maggiore o uguale a 0. La sottrazione alla riga 261 inoltre è come non esistesse, in quanto al balance dell'indirizzo verrà sottotratto sempre 0, per poi procedere con il trasferimento agli indirizzi Ethereum. Un attacco con costo zero!

Come risolvere la vulnerabilità?

Nonostante nello Smart Contract sia presente la libreria SafeMath, non è stata usata per quella moltiplicazione risultata fatale. Ecco come doveva essere la famosa riga 257!

uint256 amount = cnt.mul(_value);

SafeMath si sarebbe occupata di lanciare un'eccezione, annullando la chiamata. Il team di PeckShield riferisce di aver trovato questa vulnerabilità in più di una dozzina di Token, il cui trade sarà probabilmente bloccato dagli Exchange centralizzati.

Questo evento ci ricorda un'altra volta quanto serva prestare attenzione, studio e testing prima di rilasciare uno Smart Contract. Ricorda che puoi trovare la comunità di Coiners nel gruppo Telegram e sulla pagina Facebook!

---

Posted from my blog with SteemPress : https://www.coiners.it/analisi-di-un-uno-smart-contract-batchoverflow-come-evitarlo/

---