A major exploit in Curve.Fi’s liquidity pools due to a Vyper compiler vulnerability led to significant DeFi losses and highlighted re-entrancy issues, prompting security measures and collaboration efforts.
Key Points
- DeFi community shocked by Curve.Fi liquidity pool exploit, causing $70 million losses.
- CRV token value drops 5% amid contagion fears; AAVE lending protocol also at risk.
- Vyper compiler vulnerability analysis reveals re-entrancy issues; @nonreentrant decorator introduced.
- Vyper team addresses root cause, proposes security measures, and initiates collaborations to enhance smart contract security.
On July 30, 2023, the DeFi community was hit with a major shock as multiple Curve.Fi liquidity pools were exploited, leading to approximately $70 million in losses. The root cause of this exploit was a latent vulnerability in the Vyper compiler, specifically in versions 0.2.15, 0.2.16, and 0.3.0.
Curve Finance got hacked for over $42 million.
Hackers took advantage of a vulnerability in the Vyper programming language to hack into the Curve pools that used Vyper smart contracts.
The pools running Vyper 0.2.15, 0.2.16, and 0.3.0 were affected.
Curve devs have the… pic.twitter.com/9DoDP687fO
— dyor exchange (@dyorexchange) July 31, 2023
Contagion Fears and Decline in CRV Token Value
The impact of these hacks was significant. Not only did it result in substantial financial losses, but it also triggered concerns of contagion effects on other DeFi protocols.
The native token of Curve.Fi, known as CRV, experienced a 5% decline following the exploitation. Additionally, there were fears regarding the lending protocol AAVE, which had a massive borrow position secured by CRV token collateral.
To gain a better understanding of the incident, a report was published providing a detailed analysis of the vulnerability in the Vyper compiler, its underlying cause, and the lessons learned from the event. The report aimed to shed light on the issue and improve the security of the Vyper compiler.
Vyper is a contract-oriented, domain-specific programming language designed for the Ethereum Virtual Machine (EVM). The language prioritizes simplicity, pythonicity, security, and auditability.
Re-Entrancy: A Widespread Problem
One significant issue faced by blockchain programs is re-entrancy. It occurs when the control flow of a contract is handed over to another invoked program, enabling the invoked contract to re-enter the original caller while it is frozen.
The blockchain ecosystem has developed two primary methods to address re-entrancy attacks. The first is the Checks-Effects-Interactions (CEI) pattern, and the second is the use of re-entrancy guards. Vyper introduced a re-entrancy guard at the language level through the special `@nonreentrant` function decorator.
The introduction of `@nonreentrant` decorators dates back to the v0.1.0-beta.9 release of Vyper. However, the vulnerability stemmed from efforts to refactor the Vyper compiler’s architecture, culminating in PR#3390.
While subsequent updates attempted to address storage allocation issues, they unintentionally introduced bugs, leading to the withdrawal of v0.2.13 and v0.2.14 releases.
Issue #2393 revealed the failure of re-entrancy guard tests in v0.2.14, causing storage overlap. Although attempts were made to fix the corruption with the v0.2.15 release, this introduced a new vulnerability where all `@nonreentrant` decorators within a Vyper contract utilized a unique storage offset, regardless of their key.
This vulnerability remained undetected for four months, from July 21, 2021, to November 30, 2021, until it was finally resolved in the v0.3.1 release.
Concluding Thoughts
The vulnerability primarily affected versions 0.2.15, 0.2.16, and 0.3.0 of the Vyper compiler.
The root cause was identified as improper remediations to re-entrancy guard data corruption issues introduced in v0.2.13. This susceptibility allowed cross-function re-entrancy on all contracts compiled with these versions.
To prevent similar incidents in the future, the Vyper team proposed several measures to enhance smart contract correctness. These include improved testing, better developer tools, closer collaboration with protocols, and greater focus on securing past releases.
Furthermore, various security-related initiatives have been initiated by the Vyper team and its allies, such as short-term competitive audits, bug bounty programs, the Vyper Security Alliance, collaborations with audit firms, team expansion, integration with existing security toolkits, and the design of a language specification.
