This time we will explain two classic vulnerabilities in smart contracts: reentrancy and overflow
I believe everyone has heard about reentrancy vulnerabilities, so what are reentrancy vulnerabilities?
One of the features of Ethereum smart contract audit services is that contracts can make external calls to each other. At the same time, the transfer of Ethereum is not limited to external accounts. The contract account can also own ether and perform transfers and other operations. When the contract receives ether, it will trigger the fallback function to execute the corresponding logic, which is a hidden external call.
The audit editor first defines the reentrancy vulnerability: it can be considered that all external calls in the contract are insecure, and there may be reentrancy 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 malicious logic and then re-enter the inside of the attacked contract. way to initiate an unexpected external call, thereby affecting the normal execution logic of the attacked contract.
Our purpose is for defense, so how to avoid writing vulnerable code as a developer, and how to quickly discover problematic code as an auditor, the following editor will analyze how to prevent reentrancy vulnerabilities and how to prevent reentrancy vulnerabilities in the code. Quickly find reentrancy vulnerabilities in:
(1) As a developer
From the developer’s point of view, what we need to do is to write good code to avoid reentrancy vulnerabilities.
1. When writing code, you need to follow the coding standard of making judgment first and then writing variables to make external calls (Checks-Effects-Interactions);
2. Add anti-reentrancy lock.
(2) As an auditor of Bitan Audit Center
What we need to focus on as auditors are the characteristics of reentrancy vulnerabilities: all code locations that involve calls to external contracts are unsafe. In this way, during the auditing process, you need to focus on external calls, and then deduce the possible harm caused by external calls, so that you can judge whether this place will cause harm due to re-entry points.
As for the overflow vulnerability in the second part, let’s first take a look at what an overflow is:
There are two types of arithmetic overflow or simply overflow: overflow and underflow. The so-called overflow means that when running a single numerical calculation, when the result of the calculation is very large, which is larger than the capacity limit that the register or memory can store or represent, an overflow occurs. For example, in solidity, the range that can be represented by uint8 The 256 numbers are 0–255. When uint8 type is used to calculate 255 + 1 in actual operation, there will be overflow, so the calculated result is 0, which is the minimum value that can be represented by uint8 type. Similarly, underflow occurs when the result of a calculation is very small, less than the limit of the ability of the register or memory to store or represent. For example, in Solidity, when using uint8 type to calculate 0–1, underflow will occur, so the calculated value is 255, which is the maximum value that can be represented by uint8 type.
If a contract has an overflow loophole, smart contract audit it will cause a very large difference between the actual calculation result and the expected result, which will affect the normal logic of the contract at light level, and cause the loss of funds in the contract at severe level. However, the overflow vulnerability is limited by version. When Solidity < 0.8, overflow will not report an error, and when Solidity >= 0.8, overflow will report an error. So when we see a contract below version 0.8, we must pay attention to the possible overflow problem of this contract.
The following editor also analyzes how to prevent overflow vulnerabilities and how to quickly find overflow vulnerabilities from the perspectives of both developers and auditors:
(1) As a developer
1. Use SafeMath to prevent overflow;
2. Use Solidity 0.8 and above to develop contracts and use unchecked with caution because parameters will not be checked for overflow in unchecked modified code blocks;
3. It is necessary to use variable type coercion carefully. For example, coercion of a parameter of type uint256 to type uint8 may cause overflow due to the different value ranges of the two types.
(2) As an auditor of the Bitan Audit Center
1. First check whether the contract version is below Solidity 0.8 or whether there is an unchecked modified code block. If there is, first check the possibility of parameter overflow and determine the scope of influence;
2. If the contract version is lower than Solidity 0.8, you need to check whether the contract references SafeMath;
3. If SafeMath is used, bsc smart contract audit we need to pay attention to whether there is mandatory type conversion in the contract, if there is, there may be a risk of overflow;
4. If SafeMath is not used and there are arithmetic operations in the contract, we can think that this contract may have an overflow risk, and it should be viewed in conjunction with the actual code in the actual audit.
