Could there be a ‘super-big bug’ at the root of DeFi? It’s possible, says Blockworks Research
Blockworks Research explains Curve was the “end target” of the hack and Vyper was the means by which it took place
Paulo Melo/Shutterstock modified by Blockworks
Anyone who’s ever played a loot-based game like Diablo has heard of the old trick “duping.” An unscrupulous player places something on the ground that they want to duplicate and then tricks the inventory system into forgetting about the item when it’s picked back up.
Although it’s generally frowned upon as cheating, the tactic is relatively inconsequential, considering it’s a video game, and the inventory from which it is “stolen” has no monetary value. But in the world of cryptocurrency, where real value is traded, exploits of a similar nature can have a much more serious impact.
Such was the case with the recent attack on Curve’s DeFi ecosystem, which saw millions of dollars in tokens swiped from pools. The “re-entrancy attack” took advantage of vulnerabilities due to a bug in the compiler for Vyper, the programming language that Curve (CRV) uses for a number of smart contracts.
A re-entrancy attack doesn’t look quite the same as the old video game duping exploit, but it’s not far off. On a recent Empire podcast (Spotify/Apple), host Jason Yanowitz offers an analogy.
“Suppose that there’s this mischievous person,” Yanowitz says, who walks into a bank. To exploit the system, the scammer requests a withdrawal and promptly receives their money, but before the teller can record it in a ledger, the culprit distracts them.
While the teller is distracted, the cheat again asks for their withdrawal, at which point the teller hands over money in addition to the original funds. The process repeats with the astoundingly inattentive teller, allowing the thief to withdraw far more money than is actually in their account.
Blockworks Research analyst Ren Yu Kong explains Curve was the “end target” of the hack and Vyper, like the confused teller, allowed it to happen.
The blame game
Blockworks data editor Andrew Thurman adds that the person who approved the commit, allowing for the exploit to be executed, appears to have been a Curve developer. “It’s really tough to say it’s one team and not another team who should take the blame,” he says.
Read more: Curve’s Egorov turns to notable counterparties to bail out his DeFi positions
“These things are structures that are built on top of each other,” Thurman says. “You just assume that somebody smarter than you has done the legwork to make sure that everything’s good with the compiler.”
“Who is really at fault at the end of the day is, I think, a much more complicated question,” he says.
Yanowitz wonders if the problem extends to other protocols, considering many use the same smart contract language and compilers. Yu Kong takes things a step further.
“We all know Solidity is probably the most used smart contract programming language within the EVM ecosystem.” In a recent audit, Yu Kong notes that several bugs were discovered in Solidity’s optional compiler optimization module. “Chances are that developers check the smart contract optimization box because they trust Solidity,” Yu Kong says.
“But over the years, starting all the way from late 2018, there’s been a significant number of high-severity bugs in that Solidity compiler,” he says. “So for all we know, there’s one super big bug in the Solidity optimizer.”
Even the best Big Tech companies in the world fall victim to zero-day exploits from time to time, Yu Kong says. “It’s really hard to write perfect code.”
While Big Tech companies usually patch vulnerabilities quickly, the fact that a zero-day exploit can exist in such highly-developed software engineering environments is “pretty scary,” Yu Kong says.
“The same, probably, is the case for any smart contract programming language.”
Start your day with top crypto insights from David Canellis and Katherine Ross. Subscribe to the Empire newsletter.
