Two recently discovered vulnerabilities in some EDCCs (also called smart contracts) of ERC20 tokens have caused several cryptocurrency exchanges to suspend activities related to them.
OKEx, Changelly, Poloniex, QUOINE, and HitBTC all announced respective actions that included internal investigations as well as suspensions of deposits, withdrawals, and/or transfers of the Ethereum-based tokens.
Importantly, no vulnerabilities have been detected in the ERC20 token standard itself and, as noted by one reddit user, at least one of the two similar bugs was a function added to an EDCC.
Although these particular exploits would potentially allow hackers to gain incredibly large sums of tokens, they aren't distinctly novel in design. The Medium author noted that "batchOverflow is essentially a classic integer overflow issue," and the same can said for proxyOverflow.
With regard to computer programming, "integer overflow" is the result of a design flaw, usually occurring when mathematical operations in a given system create a value outside the representable range of the system.
The batchOverFlow exploit, for example, was discovered by tricking ERC20 contract logic in this way. According to researchers, the programmed sanity checks designed to authenticate transactions were fooled by spoofed amount values.
Rather than exploiting the ERC20 contracts with a technically complex approach, researchers highlight how mathematical creativity and rudimentary contract programming played a larger role in the discovery of this exploit, which they explained via a screenshot containing fewer than 15 lines of code.
By entering a "_value" of 8 vigintillion (which has 63 zeros), researchers invalidated the logic checks designed to validate whether the "_value" is possible or not. This was based on multiplying "cnt" by the "_value," an equation represented in line 257 of the example contract code.
The product of this equation is the "amount" and it should be mathematically verifiable. However, according to the author, a two-step process is capable of starting the batchOverFlow exploit from this position.
First, they passed two "_receivers" into the vulnerable batchTransfer function with the 8 vigintillion "_value," causing the amount to "overflow" and resetting it to zero (similar to a car's odometer that resets to zero after 999,999 miles instead of continuing on to 1 million, even though the car is still being driven).
The zeroing of the amount, as addressed in line 259, is why the contract's logic check failed. Moreover, the author noted, "With amount zeroed, an attacker can then pass the sanity checks in lines 258-259 and make the subtraction in line 261 irrelevant." Finally, in lines 262-265, the balance of both "_receivers" under the now-infracted contract would be added to the ridiculously huge "_value. "
The author expressed further concerns:
"With the touted 'code-is-law' principle in Ethereum blockchain, there is no traditional well-known security response mechanism in place to remedy these vulnerable contracts!"
Contract security has been increasingly pushed to the forefront of Ethereum initiatives as of late, especially in light of the much-debated Parity hard fork proposal.
"A proper way to recover from these vulnerabilities and devastating effects requires coordination and support from all eco-system members," wrote the author. "We cannot over-emphasize the importance of performing a thorough and comprehensive audit of smart contracts before deployment."
At press time, some exchanges, including Poloniex, have resumed support for ERC20 tokens.