Smart contract security - overflow vulnerability

The arithmetic overflow （arithmetic overflow） Or simply overflow （overflow） Divided into two ： Overflow and underflow . The so-called overflow means that when running a single numerical calculation , When the result of calculation is very large , Overflow occurs when it is greater than the capacity limit that the register or memory can store or represent ; Underflow is when the result of calculation is very small , Underflow occurs when it is less than the capacity limit that a register or memory can store or represent . for instance ： stay solidity in ,uint8 What is the range that can be expressed 0 - 255 this 256 Number .

If a contract has an overflow vulnerability, it will lead to a very big difference between the actual result of the calculation and the expected result , This light will affect the normal logic of the contract , More importantly, it will lead to the loss of funds in the contract . However, the overflow vulnerability is version Limited , stay Solidity < 0.8 No error will be reported when overflowing , When Solidity >= 0.8 When overflow occurs, an error will be reported . So when we see 0.8 For contracts under version , We should pay attention to the possible overflow of this contract .

Vulnerability example

With the above explanation , I believe everyone has a certain understanding of overflow vulnerabilities , Now let's combine the contract code to deeply understand the overflow vulnerability ：

Vulnerability analysis

TimeLock The contract acts as a time vault , The user can pass the token through deposit Function to store the contract and lock , And can't withdraw cash for at least one week . Of course, users can also use increaseLockTime Function to increase storage time , The user cannot extract before the set storage period expires TimeLock Of tokens locked in the contract . First of all, we found that in this contract increaseLockTime Functions and deposit Function has operation function , And the version supported by the contract is ：0.7.6 Upward compatibility , Therefore, this contract will not be reported wrong when it overflows , Then we can judge that there may be overflow loopholes in this contract , There are two functions available here , One is increaseLockTime function , One is deposit function . Let's first analyze the influence range of parameters in these two functions, and then decide how to launch an attack ：

1. deposit Function has two operations , The first is to affect the balance deposited by users balances Of , The parameters passed in here are controllable, so there is a risk of overflow , The other is to affect the user's locking time lockTime Of , But the arithmetic logic here is every call deposit When you deposit the token, you will give lockTime Add a week , Since the parameters here are uncontrollable, there is no overflow risk in this operation .

2. increaseLockTime The function is based on the _secondsToIncrease Parameter to change the locking time of the user's stored token , Because of the _secondsToIncrease The parameters are controllable , So there is a risk of spillover .

in summary , We find that there are two parameters available , Respectively  deposit Function balances Parameters and  increaseLockTime Function _secondsToIncrease Parameters .

Let's see first  balances  Parameters , If we want to overflow this parameter, we need enough funds to deposit （ need 2^256 A token deposit can lead to balances Overflow and return to zero ）, If you want to exploit this overflow vulnerability , We put a lot of money into our accounts and let our accounts balances Overflow and return to zero to empty your assets , I don't think anyone here would do that . Therefore, this parameter can be considered as unavailable from the perspective of the attacker .

We'll see  _secondsToIncrease  Parameters , This parameter is what we call increaseLockTime Function to increase the storage time , This parameter can determine when we can take the tokens we have deposited and locked out of the contract , We can see that this parameter is the locking time directly corresponding to the account after it is passed in lockTime To perform an operation , If we manipulate _secondsToIncrease The parameters let him in with lockTime If the result of the calculation overflows and returns to zero, can we withdraw the balance in our account before the storage date expires ？

Attack contracts

Now let's look at the attack contract ：

Here we will use Attack Attack the contract by saving it first, and then take advantage of the overflow vulnerability of the contract to extract it before the storage expires. We just TimeLock The ether stored and locked in the contract ：

1. Deploy first TimeLock contract ;

2. Redeployment Attack Contract and pass... In the constructor TimeLock The address of the contract ;

3. call Attack.attack function ,Attack.attack Call again TimeLock.deposit Functional direction TimeLock Deposit an ether in the contract （ At this time, this ether will be TimeLock Lock in for a week ）, after Attack.attack Call again TimeLock.increaseLockTime Function and pass in uint Maximum value that type can represent （2^256 - 1） Add 1 Subtract the current TimeLock The lock-in time recorded in the contract . here TimeLock.increaseLockTime Function lockTime The result of the calculation is 2^256 This value , stay uint256 Type in the 2^256 This number has overflow, so the calculation result is 2^256 = 0 At this time, we have just deposited TimeLock The lock-in time of an ether in the contract becomes 0 ;

4. At this time Attack.attack Call again TimeLock. withdraw The function will successfully pass block.timestamp > lockTime[msg.sender] This check allows us to successfully withdraw the storage time before it expires. We just TimeLock The ether stored and locked in the contract .

The following is the attack flow chart ：

Repair suggestions

Next , Let's talk about how to fix these vulnerabilities ？ Obviously , Preventing data value overflow can fix these vulnerabilities , Then I'll give you some suggestions to prevent data value overflow ！

1. Use Solidity 0.8 And above versions to develop contracts , There's another point here ： You need to be careful with unchecked, Because in unchecked There is no overflow check for parameters in the modified code block ;2. Use SafeMath Method library ,SafeMath Only four simple operation methods are provided , But when calculating overflow , It throws an error ;

besides , As a contract writer , You also need to be careful with variable type coercion , Because of different types , Its numerical range is different , Type cast may cause numeric overflow .

If you want to know more about smart contracts and blockchain , Welcome to blockchain communication community CHAINPIP Community , Exchange and study together ~

Community address ：https://www.chainpip.com/