0x01 溢出攻击事件

2018年4月22日，黑客对BEC智能合约发起攻击，凭空取出：

57,896,044,618,658,100,000,000,000,000,000,000,000,000,000,000,000,000,000,000.792003956564819968 个BEC代币并在市场上进行抛售，BEC随即急剧贬值，价值几乎为0，该市场瞬间土崩瓦解。

2018年4月25日，SMT项目方发现其交易存在异常，黑客利用其函数漏洞创造了：

65,133,050,195,990,400,000,000,000,000,000,000,000,000,000,000,000,000,000,000+50,659,039,041,325,800,000,000,000,000,000,000,000,000,000,000,000,000,000,000 的SMT币，火币Pro随即暂停了所有币种的充值提取业务。

2018年12月27日，以太坊智能合约Fountain(FNT)出现整数溢出漏洞，黑客利用其函数漏洞创造了：

2+115792089237316195423570985008687907853269984665640564039457584007913129639935 的SMT币。

历史的血泪教训，如今不该再次出现。让我们一起缅怀这些一夜归零的代币，吸取前人经验教训。

0x02 整数溢出简介

• 整数溢出原理

由于计算机底层是二进制，任何十进制数字都会被编码到二进制。溢出会丢弃最高位，导致数值不正确。

如：八位无符号整数类型的最大值是 255，翻译到二进制是 1111 1111；当再加一时，当前所有的 1 都会变成 0，并向上进位。但由于该整数类型所能容纳的位置已经全部是 1 了，再向上进位，最高位会被丢弃，于是二进制就变成了 0000 0000

注：有符号的整数类型，其二进制最高位代表正负。所以该类型的正数溢出会变成负数，而不是零。

• 整数溢出示例（通用编程语言）

编程语言由算数导致的整数溢出漏洞司空见惯，其类型包括如下三种：

• 加法溢出

• 减法溢出

• 乘法溢出

我们先以运行在 JVM 上的 Kotlin 编程语言做加法运算来测试整数溢出为例：

fun main() {
   println(Long.MAX_VALUE + 1) // Long 是有符号的 128 位 Integer 类型
}

程序会打印出 -9223372036854775808，这其实是在编译期就没有防止整数溢出，因为编译器让溢出的代码通过编译了。

当然，也有在编译期严格检查整数溢出的编程语言。如区块链世界最火的 Rust 编程语言：

fn main() {
    dbg!(u128::MAX + 1); // u128 是无符号的 128 位 Integer 类型
}

编译这段代码，你会得到编译错误：

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

很好，这有效阻止了编译期溢出的问题。那么，如果是运行时呢？我们来读取用户输入试试：

fn main() {
    let mut s = String::new();
    std::io::stdin().read_line(&mut s).unwrap();
    dbg!(s.trim_end().parse::<u8>().unwrap() + 1); // u8 是无符号的 8 位 Integer 类型
}

运行 cargo r，输入：255，得到 panic：

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

可以看到，在 debug 模式下，溢出会直接 panic，也就是：程序崩溃掉、停止工作。那么，release 模式下也是这样吗？

运行 cargo r --release，输入：255，打印：

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

综上，我们得到一条结论：即使在编译期严格检查溢出的程序语言，依然会有整数溢出问题。整数溢出就好像是一个魔咒，总会隔三岔五地出现，无法一劳永逸地消除。

• 智能合约中的整数溢出（Solidity 语言）

在区块链的世界里，智能合约的 Solidity 语言中，对于 0.8.0 以下的版本，也存在整数溢出问题。

和通用型编程语言一样，我们先看看编译期是否会发生溢出：

实测，测试函数会直接发生编译错误。再来看看运行时：

实测，程序会在运行时溢出。我们建议使用 SafeMath 库来解决漏洞溢出：

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;
  }
}

对于 Solidity 0.8.0 以上的版本，官方已经修复了这个问题。那么它到底是如何修复的？将要溢出时会发生什么来防止溢出呢？

实测，Solidity 0.8 以上的版本发生运行时溢出会直接 revert。

原来，修复的方式就是不允许溢出。int256 足够大，只要保证无法被黑客利用这一点凭空创造收益，我们就成功了。

0x03 漏洞合约、攻击手法

以 BEC 合约为例，合约地址为：

0xC5d105E63711398aF9bbff092d4B6769C82F793D

在 etherscan 上的地址为：

https://etherscan.io/address/0xc5d105e63711398af9bbff092d4b6769c82f793d#code

存在溢出漏洞的合约代码如下：

function batchTransfer(address[] _receivers, uint256 _value) public whenNotPaused returns (bool) {
    uint cnt = _receivers.length;
    uint256 amount = uint256(cnt) * _value; //溢出点，这里存在整数溢出
    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;
  }

当时的合约版本是 ^0.4.16，小于 0.8 版本，也没有使用 SafeMath 库，因此存在整数溢出问题。

黑客传入了一个极大的值（这里为2**255），通过乘法向上溢出，使得 amount（要转的总币数）溢出后变为一个很小的数字或者0（这里变成0），从而绕过 balances[msg.sender] >= amount 的检查代码，使得巨大 _value 数额的恶意转账得以成功。

实际攻击的恶意转账记录：

https://etherscan.io/tx/0xad89ff16fd1ebe3a0a7cf4ed282302c06626c1af33221ebe0d3a470aba4a660f

0x04 总结

在 Solidity 0.8 版本以下，且未使用 SafeMath 库的情况下：黑客往往会利用溢出构造一个极小值/极大值，从而绕过某些检查，使巨额恶意转账得以成功。

当然，合约漏洞不仅仅只有整数溢出。除了开发者自身提高安全开发意识外，寻找专业的安全团队对合约进行全面的审计也是非常有必要的。