You can hardly find a more exploited vulnerability in Web3 than reentrancy. Older than Solidity itself, this type of cyberattack is technically in a whole different league from other security issues in DeFi.
The word reentrancy stems from the sphere of general computing. Reentrancy occurs each time program execution is interrupted and gets restarted, with no errors visible even though both operations run completed. In DeFi, a reentrancy attack introduces flawed logic into smart contracts, sometimes leading to devastating losses.
That being said, not every reentrant behavior can be called a bug. It can turn into a critical security issue if two conditions are met:
This is how an average reentrancy attack is launched step-by-step:
You’ll hear more stories about another one biting the dust due to reentrancy. How big can the losses be? Let’s list some of the exploits of this kind that has been in the spotlight for the last few years:
Still, the most notorious exploit using the reentrancy vulnerability happened on June 17, 2016, when a bad actor siphoned 3.6 mln ETH from TheDao’s smart contract (about 5% of all ETH at that time). Quite sophisticated, the attack involved creating a child DAO and calling several functions. The hacker managed to transfer funds to his personal wallet only 41 days later. In the meantime, the entire crypto community was discussing possible solutions. Eventually, these debates led to the creation of a hard fork of Ethereum that was named Ethereum Classic.
A possibility to re-enter the function for the message sender was detected during the audit of Colexion’s smart contracts. Provided someone initiated a transaction from the contract with a fallback function, they would be able to reenter the function repeatedly which presented a critical issue. The client was recommended to update the balance to zero before making the transaction. Status: Fixed
Reentrancy typically occurs across multiple functions or contracts, so preventing reentrancy within a single function is not enough. You have to finish all state changes before calling an external function.Yevhenii Bezuhlyi, Head of Audits
One of the ways to prevent reentrancy attacks is to use the checks-effects-interactions design while coding smart contracts. It requires structuring the functions in a certain order to make sure all state changes occur internally prior to calling external smart contracts.
Not all contracts can be created using this design. In some cases, a mutex is used to render a certain function non-reentrant. This special modifier locks the current state so that any malicious attempts will be reverted at all times. As great as it may sound, mutex is far from being a universal solution. Unfortunately, it can severely limit platform capabilities, especially when it comes to multi-platform architecture. What’s more, coding with mutexes might bring about livelocks and deadlocks.
Even the best Solidity programmers make mistakes when working under tight deadlines. It is crucial for DeFi projects to get their smart contracts thoroughly checked by trusted Web3 cybersecurity auditors like Hacken.
Enter your email address to subscribe to Hacken Reseach and receive notifications of new posts by email.