Drowning Smart Contracts: Overflow and Underflow

by ImmuneBytes
Overflow and Underflow

We are back with the next part of All About Smart Contract Bugs & Security A cakewalk series, explaining to you one of the most commonly overlooked bugs that can weaken a smart contract, Integer Overflow, and Underflow. Make sure to check out the other parts in this series to know about Timestamp Dependence and Re-entrancy, and how these bugs affect smart contracts.

Remember the havoc caused during the turn of the millennium by the class of a computer bug? The Y2K problem, where 2000 was reverted back to 1900 as many programs depicted four-year digits with only two digits, which became problematic for many companies when the year changed from 1999 to 2000. This is the case of an Integer overflow bug, where the number gets incremented beyond its maximum value. 

Consider an unsigned 8-bit integer i.e it can take decimal numbers between 0-255. Further incrementing it by 1 would to an overflow situation:

uint8 a = 255;

a++;

Similarly, in the case of underflow, the minimum value a number can take is zero and any further decrement causes the code to collapse.

uint8 a = 0;

a–;

What happens in the case of a blockchain, take a look at the code below:

mapping (address => uint256) public balanceOf;

function transfer(address _to, uint256 _value) {

    /* Check if sender has balance */

    require(balanceOf[msg.sender] >= _value);

    /* Add and subtract new balances */

    balanceOf[msg.sender] -= _value;

    balanceOf[_to] += _value;

}

If the balance reaches the maximum value of uint (2^256), it is going to circle back and make it 0 which can prove to be very problematic.

How can we fix this?

The first and foremost thing you need to do is look for a renowned third-party auditing company and get your smart contract code audited. ImmuneBytes is one such company that offers to secure your smart contract.

However, let’s anyway take a look at the secure form of the above-mentioned code:

function transfer(address _to, uint256 _value) {

    /* Check if sender has balance and for overflows */

    require(balanceOf[msg.sender] >= _value && balanceOf[_to] + _value >= balanceOf[_to]);

 

    /* Add and subtract new balances */

    balanceOf[msg.sender] -= _value;

    balanceOf[_to] += _value;

}

If in case only the admin has access to change the variable’s state, you might be safe. Also, if a user is allowed to increment by only 1 at a time, you are probably also safe because there is no feasible way to reach this limit.

Additional Resource: Top 10 Smart Contract Vulnerabilities

Real-World Example: $800K drained from PoWH Coin Ponzi Scheme

On Feb 1, 2018, 4chan’s /biz/ amalgamated and created a cryptocurrency Ponzi Scheme: Proof of Weak Hands Coin, advertising it as a legit pyramid scheme. Surprisingly, its value quickly escalated to over a million dollars and over a thousand Ethereum. Although, soon after that 866 ETH dissipated from the contract. How did that happen? Let’s find out.

function transferFrom(address _from, address _to, uint256 _value)  public {

   var _allowance = allowance[_from][msg.sender];

   if (_allowance < _value)

       revert();

   allowance[_from][msg.sender] = _allowance – _value;

   transferTokens(_from, _to, _value);

}

transferFrom, the flawed function allowed a user to “rubber-stamp” another user to transfer ETH. A malicious user could sell the tokens of one account using another account, triggering an underflow and leaving the attacker with the maximum possible sum of money.

In just 282 lines of code, PoWH Coin managed to lose approximately $800 thousand because of a flawed code that could have been easily fixed if it was audited.

This was ImmuneBytes’ take on the Overflow and Underflow bug along with a real-world example to show you what consequences one has to face when deciding to go forth with an unaudited code. Connect with the team of security professionals at ImmuneBytes today to get your smart contract free of any vulnerabilities and loopholes.

Tune in next Thursday for Part-V of this series wherein we discuss the Stack Size Limit in smart contracts.

Spread the love

You may also like