Introduction to Smart Contract Security Audit: Re-entry Vulnerability

Background overview

I saw a site about learning solidity (https://solidity-by-example.org), which talked about many vulnerabilities in solidity smart contracts. Considering that attacks against smart contracts happen frequently now, criminals stole them There are more and more encrypted assets, I want to write some articles related to smart contract security audits for beginners who want to understand smart contract security audits, so that some beginners who are interested in smart contract security audits can learn how to identify some Common vulnerabilities and how to use these vulnerabilities to do things. This time we will first look at a very classic loophole-  reentrance loophole .

Pre-knowledge

I believe everyone has heard of reentrancy vulnerabilities, so what is a reentrancy vulnerability?

One of the characteristics of Ethereum smart contracts is that the contracts can make external calls to each other. At the same time, the transfer of Ethereum is not limited to external accounts. Contract accounts can also have ether and perform transfers and other operations, and when the contract receives ether, it will trigger the fallback function to execute the corresponding logic, which is a hidden external call.

Let’s first define the reentrancy vulnerability: it can be considered that all external calls in the contract are insecure, and there may be reentrance vulnerabilities. For example: if the target of the external call is a malicious contract that the attacker can control, then when the attacked contract calls the malicious contract, the attacker can execute the malicious logic and then re-enter the inside of the attacked contract, through this In order to initiate an unexpected external call, it will affect the normal execution logic of the attacked contract.

Vulnerability example

Okay, after reading the above pre-knowledge, I believe that everyone has a general understanding of reentrancy vulnerabilities. Then in a real environment, what kind of code developers write will have reentrance vulnerabilities. Let’s look at it below. A typical code with reentrancy vulnerability:

zkFZWwgcUQdGiFcbWgisLCdCdukRXTr8tgoyBywl.png

Vulnerability analysis

When you see this, everyone may be confused. The above code is just a normal deposit and withdrawal contract. Why does it say that he has a reentry attack? Let’s look at the withdraw function of this contract. The transfer operation in this function has an external call (msg.sender.call{value: bal}), so we can think that this contract may have a reentrance vulnerability, but the specific function More in-depth analysis is needed for harm:

1. All external calls are unsafe and the contract will trigger the fallback function to execute the corresponding logic when receiving ether. This is a hidden external call. Will this hidden external call cause harm?

2. We can see that in the withdraw function, the account balance is cleared after the external call is executed for the transfer, so can we construct a malicious logic contract when the transfer is externally called and execute balance[msg.sender in the contract ]=0 How about calling the withdraw function in a loop to withdraw coins to clear the contract account?

Let’s see if the attack methods in the attack contract written by the attacker are the same as our vulnerability analysis:

Attack contract

Cj4yQoBvGT1p2LCeT8HOOWxfiPlup0v7iXgeoG3T.png

We see that the EtherStore contract is a deposit and withdrawal contract in which we can deposit and withdraw Ether. Below we will use the attack contract to clear the user’s balance in the EtherStore contract:

Here we will quote three roles, namely:

Users: Alice, Bob

Attacker: Eve

1. Deploy the EtherStore contract;

2. User 1 (Alice) and user 2 (Bob) both recharge 1 Ether into the EtherStore contract;

3. The attacker Eve passed in the address of the EtherStore contract when deploying the Attack contract;

4. The attacker Eve calls the Attack.attack function, and Attack.attack calls the EtherStore.deposit function to recharge 1 ether to the EtherStore contract. At this time, there are 3 ethers in the EtherStore contract, which are Alice and Bob’s 2 ethers. And the 1 ether that the attacker Eve just recharged. Then Attack.attack calls the EtherStore.withdraw function to take out the Ether that it just recharged. At this time, there are only two Ethers of Alice and Bob left in the EtherStore contract;

5. When Attack.attack calls EtherStore.withdraw to withdraw 1 Ether from the previous Eve recharge, the Attack.fallback function will be triggered. At this time, as long as the ether in the EtherStore contract is greater than or equal to 1 Attack.fallback, the EtherStore.withdraw function will be called to withdraw the ether from the EtherStore contract to the Attack contract until the ether in the EtherStore contract is less than 1. In this way, the attacker Eve will get the remaining 2 Ether in the EtherStore contract (the two Ether recharged by Alice and Bob).

The following is the function call flow chart of the attacker:

Introduction to Smart Contract Security Audit: Re-entry Vulnerability

Repair suggestions

After reading the above attack methods, I believe that everyone will have their own knowledge of reentry vulnerabilities, but only attacks are not good. Our purpose is to defend, so how do you avoid writing vulnerable code as a developer and how to be an auditor? To quickly find the problem code, let’s use these two identities to analyze how to defend against reentry vulnerabilities and how to quickly find reentry vulnerabilities in the code:

(1) As a developer

From the developer’s point of view, what we need to do is write good code to avoid reentrancy vulnerabilities.

1. When writing code, you need to follow the coding standard (Checks-Effects-Interactions) of first judgment, and then write variables in external calls;

2. Add anti-reentry lock.

The following is a code example of anti-reentry lock:

BoR5VSNmaeY571ujIUhPpjYdKx4ZaPy7erW0EXiK.png

(2) As an auditor

As auditors, we need to pay attention to the characteristics of reentrancy vulnerabilities: all code locations involved in external contract calls are insecure. In this way, we need to focus on external calls during the audit process, and then deduce the possible harm of external calls, so that we can judge whether this place will cause harm due to the re-entry point.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/introduction-to-smart-contract-security-audit-re-entry-vulnerability/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2021-12-09 08:33
Next 2021-12-09 08:37

Related articles