Rob Behnke
May 17th, 2022
Re-entrancy is a common smart contract vulnerability. While it can exist in smart contracts on various blockchain platforms, it is most often associated with the Ethereum blockchain.
Re-entrancy attacks are most well-known due to the famous 2016 DAO hack on the Ethereum blockchain. However, these vulnerabilities also have cropped up in multiple smart contract hacks, including several DeFi protocols.
The potential for re-entrancy attacks in Ethereum smart contracts arises from how transfers of value are handled on Ethereum. Ethereum treats user and smart contract accounts the same, so both can make a call to a smart contract or receive a transfer of Ether.
If Ether is transferred to an address containing smart contract code, then that smart contract is given the chance to run some code. This “fallback function” could be used to update internal state based on the transfer or take other actions triggered by the deposit (such as issuing some token in response).
Logically, smart contract functions such as withdrawal functions would follow a check-interaction-effects pattern. This means that they would verify a withdrawal is valid, perform the transfer requested in the withdrawal, and then update their internal state based on the withdrawal (i.e. saying that the value was debited from the user’s account).
However, this code pattern creates a re-entrancy vulnerability due to the existence of Ethereum’s fallback functions. At the interaction stage of the process, a smart contract that called the vulnerable function has the ability to run the code in its fallback function.
If this code calls the vulnerable function again, the second iteration of the code would occur before the function performed its internal update.
For example, consider the following sequence of events:
Between steps 3 and 6, the vulnerable function transfers 8 ETH to the malicious smart contract despite the fact that the malicious contract’s account only contained 5 ETH. This is possible because the vulnerable function only performs its state updates after the transfer has been made and the malicious contract has the chance to run the code contained within its fallback function.
The DAO hack is the most famous example of a re-entrancy hack, and it occurred in June 2016. However, re-entrancy vulnerabilities are still resulting in major hacks nearly six years later.
Some examples of recent DeFi hacks that involved re-entrancy vulnerabilities include:
These are far from the only examples of DeFi hacks that exploited re-entrancy vulnerabilities. Despite being an old and well-publicized risk, re-entrancy vulnerabilities are still appearing in new smart contracts today.
Re-entrancy attacks are made possible by the use of a logical but insecure code pattern when performing transfers within Ethereum smart contracts. The check-interaction-effects code pattern allows a malicious smart contract to execute the code in its fallback function and reenter a vulnerable function before it has the opportunity to update its internal state.
Re-entrancy vulnerabilities can be avoided by using the check-effects-interaction code pattern, where state updates are performed before the value transfer that they record. If this had occurred in the example above, the check at line 5 would have failed because the attacker’s account balance would already have been updated to a value of 1.
One of the common threads among DeFi smart contracts that fall prey to re-entrancy hacks is that they did not undergo a security audit before the launch of the vulnerable code. Re-entrancy vulnerabilities are a well-known threat that should be identified and remediated as part of a security audit.
To learn more about protecting your smart contracts against re-entrancy attacks and other security vulnerabilities, reach out to Halborn’s smart contract auditing team at halborn@protonmail.com.