reentrant attack
Re-entrancy attacks only apply to smart contracts due to the nature of external calls. When a contract interacts with another contract through an external call, such as during a token transfer, the receiving contract can execute arbitrary code in response. This execution may lead to unexpected behavior that was not anticipated by the original contract programmer.
In a reentrancy attack, the receiving contract takes advantage of an external call by calling a function recursively before the first call completes. This behavior is different from simply calling a function once and could lead to a security breach. From a developer’s perspective, these executions are difficult to prevent because it is difficult to predict and imagine how they might occur. There are a variety of scenarios in which re-entry can be utilized. This article provides a simple example of a re-entrancy attack and how to prevent it.
Single function reentrancy attack analysis
This is the source code of a simple vault contract that allows users to deposit and withdraw funds. The withdraw function is vulnerable to re-entrancy attacks.
A call comes from outside msg.senderat withdraw function. This is where re-entrancy attacks can occur. An attacker can make a phone call. withdraw It operates multiple times before the first call completes, resulting in unexpected behavior.
Let’s analyze the code execution. withdraw function. The problem with this function is that it updates the value after the outer call. Below is how. withdraw Function operation:
1. uint256 amount = balances(msg.sender);2. // send ETH amount of ETH value // whatever the user can do as a function call3. balances(msg.sender) = 0;So we withdraw function is equivalent to calling two functions.
- Calculate the amount and send ETH.
- Set your balance to 0.
The requirement is that other functions can run after the first function is completed, but eventually the second function must run.
From the above analysis, we can understand the concept of reentrancy, which is calling a function again from within the user’s external function.
Let’s consider the following scenario: This is allowed because the execution meets the above requirements. But a problem occurred.
1. uint256 amount = balances(msg.sender);2. // send ETH amount of ETH value // call withdraw() again2.1. uint256 amount2 = balances(msg.sender);2.2. // send ETH amount2 of ETH value // only receive value, nothing else this time.2.3. balances(msg.sender) = 0;3. balances(msg.sender) = 0;As a result of this execution, the user will receive as a balance double the amount of ETH held in this contract. However, the run was still successful. Similarly, you can do it 10 times or you can do it 100 times. Users can receive 100 times the amount of ETH held in this contract as balance.
Attack example
This is an example of an attacker contract.
This is Wake’s test file.
Deploy the vault, store 10 ETH, and distribute the attacker contract with 1 ETH.
By calling attacker_contract.attack() The attack function in the attacker contract is called from a function in the Python test code.
In the attack function, 1 ETH is deposited into the vault and withdrawn from the vault. The withdraw function calls an external call to send ether to the attacker. Therefore, the receive function of the attacker contract is called. at receive() The function calls: withdraw Functional again.
Call tracing for attacks. The attacker contract has 1ETH and the vault contract has 10ETH. After the 5th withdraw By calling the function recursively, there are 6 ETH in the attacker’s contract and 5 ETH in the storage.
This is a single-function reentrancy attack. Most other reentrancy attacks are based on this scenario. However, the complexity and functional structure of the project makes it difficult to detect.
Prevention
There are several ways to prevent this attack. Although these prevention methods are effective against single-function reentrancy attacks, they are not guaranteed to prevent all reentrancy attacks.
Here are some common methods:
re-entry guard
ReentrancyGuard makes it impossible to renew your contract.
After external call, check and write the value.
The unexpected execution flow of the above attack includes resetting the balance to zero twice. This reset assumes that your previous balance value is the same as your current balance value. sheep, but it changes. This example shows how programmers fail to anticipate reentrancy.
Change the code that deducts amounts from the balance to properly manage the user’s balance.
Confirmation-Effect-Interaction
Another preventative method is to first finish changing the state of the function and then call the external function. As explained above, a function call can be viewed as two separate function calls. We disable the attack by having the second part of the function do nothing.
conclusion
In conclusion, understanding and preventing re-entrancy vulnerabilities is important to develop secure smart contracts. For example, even though there are other types of reentrancy attacks, ReentrancyGuard is not sufficient to completely prevent some contracts. It is important to understand the concept of reentry and how to utilize it.
There is a reentrant example Github repository. There are other types of reentrancy attacks and also protocol-specific reentrancy attacks.
We also discussed different types of reentrancy and protocol-specific reentrancy in the blog.
You can write reentrancy attacks and learn how they work in practice.
