Zero time technology | solid smart contract basic vulnerability - Integer Overflow Vulnerability


0x01 overflow attack event

On April 22, 2018, hackers launched an attack on BEC smart contract and took out:

5789604461865810000000000000000000000000000000000000000000000000000000000000000000000000000.792003956564819968 BEC tokens were sold in the market. BEC depreciated sharply and its value was almost zero. The market collapsed instantly.

On April 25, 2018, the SMT project side found that there were abnormalities in its transaction, and hackers used its function vulnerabilities to create:

65133050195990400000000000000000000000000000000000000000000000000000000000 + 50659039041325800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.

On December 27, 2018, an integer overflow vulnerability occurred in Ethereum smart contract Fountain(FNT). Hackers took advantage of its function vulnerability to create:

2 + 115792089273161954235709850086879078532699846656405640394575840079132963935 SMT coins.

The bloody and tearful lessons of history should not appear again today. Let's cherish the memory of these tokens that returned to zero overnight and learn from the experience and lessons of our predecessors.

0x02 introduction to integer overflow

  • Integer overflow principle

Since the bottom of the computer is binary, any decimal number will be encoded into binary. Overflow discards the highest bit, resulting in incorrect values.

For example, the maximum value of an eight bit unsigned integer type is 255, which is 1111 when translated into binary; When you add one more time, all current 1s will become 0 and carry up. However, since the positions that can be accommodated by this integer type are all 1, and then carry up, the highest bit will be discarded, so the binary becomes 0000

Note: for signed integer type, its binary highest bit represents positive and negative. Therefore, positive overflow of this type will become negative instead of zero.

  • Integer overflow example (general programming language)

Integer overflow vulnerabilities caused by arithmetic are common in programming languages. There are three types:

• additive overflow

• subtraction overflow

• multiplication overflow

Let's take the addition operation of Kotlin programming language running on the JVM to test integer overflow as an example:

fun main() {
   println(Long.MAX_VALUE + 1) // Long is a signed 128 bit Integer type

The program will print - 9223372036854775808, which is actually that integer overflow is not prevented during compilation, because the compiler allows the overflow code to be compiled.

Of course, there are programming languages that strictly check integer overflow at compile time. For example, the blockchain world's hottest Rust programming language:

fn main() {
    dbg!(u128::MAX + 1); // u128 is an unsigned 128 bit Integer type

If you compile this code, you will get a compilation error:

error: this arithmetic operation will overflow
 --> src/
2 |     dbg!(u128::MAX + 1);
  |          ^^^^^^^^^^^^^ attempt to compute `u128::MAX + 1_u128`, which would overflow
  = note: `#[deny(arithmetic_overflow)]` on by default

Well, this effectively prevents the problem of compile time overflow. So what if it's runtime? Let's try reading user input:

fn main() {
    let mut s = String::new();
    std::io::stdin().read_line(&mut s).unwrap();
    dbg!(s.trim_end().parse::<u8>().unwrap() + 1); // u8 is an unsigned 8-bit Integer type

Run cargo r and enter 255 to get panic:

thread 'main' panicked at 'attempt to add with overflow'

It can be seen that in the debug mode, the overflow will directly panic, that is, the program crashes and stops working. So, is this also true in release mode?

Run cargo r --release, input: 255, print:

[src/] s.trim_end().parse::<u8>().unwrap() + 1 = 0

To sum up, we come to a conclusion: even if the overflow program language is strictly checked during compilation, there will still be integer overflow. Integer overflow is like a magic spell. It always appears every once in a while and cannot be eliminated once and for all.

  • Integer overflow in smart contract (solid language)

In the world of blockchain, the solid language of smart contract also has integer overflow problem for versions below 0.8.0.

Like general-purpose programming languages, let's first look at whether overflow occurs during compilation:


Actually, the test function will directly generate compilation errors. Let's look at the Runtime:


Actually, the program will overflow at runtime. We recommend using the SafeMath library to resolve the vulnerability overflow:

library SafeMath {
  function mul(uint256 a, uint256 b) internal constant returns (uint256) {
    uint256 c = a * b;
    assert(a == 0 || c / a == b);
    return c;

  function div(uint256 a, uint256 b) internal constant returns (uint256) {
    uint256 c = a / b;
    return c;

  function sub(uint256 a, uint256 b) internal constant returns (uint256) {
    assert(b <= a);
    return a - b;

  function add(uint256 a, uint256 b) internal constant returns (uint256) {
    uint256 c = a + b;
    assert(c >= a);
    return c;

For the version above Solidity 0.8.0, the official has fixed this problem. So how is it repaired? What happens to prevent overflow when it is about to overflow?

According to the actual measurement, the run-time overflow of the version above 0.8 will be directly reversed.

Originally, the way to repair is not to allow overflow. int256 is big enough. As long as we ensure that it cannot be used by hackers to create revenue out of thin air, we will succeed.

0x03 vulnerability contract and attack tactics

Take BEC contract as an example. The contract address is:


The address on etherscan is:

The contract code with overflow vulnerability is as follows:

function batchTransfer(address[] _receivers, uint256 _value) public whenNotPaused returns (bool) {
    uint cnt = _receivers.length;
    uint256 amount = uint256(cnt) * _value; //Overflow point, where integer overflow exists
    require(cnt > 0 && cnt <= 20);
    require(_value > 0 && balances[msg.sender] >= amount);

    balances[msg.sender] = balances[msg.sender].sub(amount);
    for (uint i = 0; i < cnt; i++) {
        balances[_receivers[i]] = balances[_receivers[i]].add(_value);
        Transfer(msg.sender, _receivers[i], _value);
    return true;

At that time, the contract version was ^ 0.4.16, which was less than version 0.8, and the SafeMath library was not used, so there was an integer overflow problem.

The hacker passes in a maximum value (2 * * 255 here) and overflows upward through multiplication, so that the amount (total coins to be transferred) overflows and becomes a very small number or 0 (0 here), thus bypassing the check code of balances [MSG. Sender] > = amount and making it huge_ The malicious transfer of value was successful.

Malicious transfer record of actual attack:

0x04 summary

Under the condition of solidity version 0.8 and without using SafeMath Library: hackers often use overflow to construct a minimum / maximum value, so as to bypass some checks and make huge malicious transfers successful.

Of course, the contract vulnerability is not just integer overflow. In addition to the developers themselves to improve their awareness of security development, it is also very necessary to find a professional security team to conduct a comprehensive audit of the contract.

Keywords: security

Added by php3ch0 on Thu, 24 Feb 2022 10:11:04 +0200