What Is a Re-entrancy Attack?

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:

1. Malicious contract M calls the vulnerable function F attempting to withdraw 4 ETH from an account containing 5 ETH
2. F checks that the withdrawal is valid, and, since 5 > 4, approves it
3. F transfers the requested 4 ETH to M
4. This transfer triggers M’s fallback function, which calls F again requesting a withdrawal of 4 ETH
5. F checks that the withdrawal is valid, and, since M’s account balance is still 5 and 5 > 4, approves it
6. F transfers the requested 4 ETH to M
7. M’s fallback function returns without performing any action
8. F updates its state to reflect the withdrawal in step 6, reducing M’s account balance to 1 ETH
9. F returns, which hands over control to M’s fallback function from step 4
10. M’s fallback function returns without performing any action
11. F updates its state to reflect the withdrawal in step 3, reducing M’s account balance to -2 ETH
12. F returns control to M, which ends the transaction

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:

• Fei Protocol: In April 2022, the Fei protocol was the victim of an ~$80 million hack that was made possible by its use of third-party code containing re-entrancy vulnerabilities.
• Paraluni: A March 2022 hack of the Paraluni smart contract exploited a re-entrancy vulnerability and poor validation of untrusted user input to steal ~$1.7 million in tokens.
• Grim Finance: In December 2021, a re-entrancy vulnerability in Grim Finance’s safeTransferFrom function was exploited for ~$30 million in tokens.
• SIREN Protocol: A re-entrancy vulnerability in the SIREN protocol’s AMM pool smart contracts was exploited in September 2021 for ~$3.5 million in tokens.
• CREAM Finance: In August 2021, an attacker took advantage of a re-entrancy vulnerability in CREAM Finance’s integration of AMP tokens to steal approximately $18.8 million in tokens.

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.