Solidity合约中的整数溢出漏洞事件

事件

2018年4月23日 BEC 一夜被偷64亿

2018年4月25日 SMT 再爆类似漏洞，火币Pro和OKEx相继暂停了SMT交易

2018年4月25日 BEC、SMT现重大漏洞，这8个智能合约也可能凉凉（MESH、UGToken、SMT、SMART、MTC、FirstCoin、GG Token、CNY Token、CNYTokenPlus）

原因

Solidity合约中的整数溢出漏洞

分析

BEC

合约代码地址：https://etherscan.io/address/0xc5d105e63711398af9bbff092d4b6769c82f793d#code

可以看到batchTransfer函数中
, 261 行语句 balances[msg.sender] = balances[msg.sender].sub(amount)和
263行语句 balances[_receivers[i]] = balances[_receivers[i]].add(_value)
中，调用 Safemath库中的安全函数来完成加减操作，但是在第257行代码， uint256 amount = uint256(cnt) * _value 却直接使用乘法运算符。

其中变量cnt为转账的地址数量，可以通过外界的用户输入
_receivers进行控制， _value为单地址转账数额，也可以直接进行控制。乘法运算溢出，产生了非预期 amount
数值，并且外界可以通过调整_receivers 和_value 的数值进行操控。紧接着下面有一句对 amount进行条件检查的代码
require(_value > 0&& balances[msg.sender] >= amount); 其中
balances[msg.sender]代表当前用户的余额。amount代表要转的总币数。代码意思为确保
当前用户拥有的代币余额大于等于转账的总币数才进行后续转账操作。因为通过调大单地址转账数额 _value的数值，amount
溢出后可以为一个很小的数字或者0 ，很容易绕过balances[msg.sender] >= amount
的检查代码。从而产生巨大_value数额的恶意转账。

SMT

合约代码地址：https://etherscan.io/address/0x55f93985431fc9304077687a35a1ba103dc1e081#code

问题存在于transferProxy()函数中，在进行加法操作的时候没有采用Safemath库进行约束。
_feeSmt参数和 _value参数均可以被外界进行控制， _feeSmt和 value均是 uint256
无符号整数，相加后最高位舍掉，结果为0。

在第 206 行代码 if(balances[_from] < _feeSmt + _value) revert(); 直接使用加法来完成被外界可控的参数进行操作。后面也没有使用Safemath库中的安全函数来完成运算操作。

解决

为了解决整数溢出的问题，以太坊官方在 2017年 8月 6日 单独发过一篇使用SafeMath 库进行整数安全操作的文章（见文后链接） 。Solidity中的SafeMath库定义如下：

下面显示了使用示例：

总结

单纯从技术上来说，smt和bec的本次合约的漏洞成因和利用都不复杂，均是通过构造恶意的整数溢出绕过条件检查。相信以太坊生态下的其他数千种代币的合约也不同程度的存在类似的整数漏洞安全隐患，由于solidity合约是直接跟钱打交道，合约的安全开发和审计值得ico项目方和solidity开发人员投入更多时间和精力，确保合约的安全性。

参考

一行代码蒸发了¥6,447,277,680 人民币！

https://zhuanlan.zhihu.com/p/35989258

Solidity合约中的整数安全问题——SMT BEC合约整数溢出解析

http://www.freebuf.com/vuls/169741.html

BEC、SMT现重大漏洞，这8个智能合约也可能凉凉

http://36kr.com/p/5131152.html

SafeMath to protect from overflows

https://ethereumdev.io/safemath-protect-overflows/