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

1 整数安全回顾

1.1 整数安全简介

在传统的桌面windows攻防对抗领域，伴随着微软和合作伙伴对软件开发流程推行SDL规范，同时对安全投入的逐步加大，单一的封包超长和文件特定字段内容超长导致的溢出漏洞在一些大型软件里几乎绝迹。剩余漏洞除了浏览器中的UAF(有隔离堆和延迟释放对关键类进行利用缓解)，弱类型语言存在的类型混淆，还零星剩下了一些整数类的漏洞。整数类漏洞，最近的如去年的nginx cve-2017-7529。

区块链方向，比较早的整数溢出类漏洞可追溯到2010年的比特币大整数溢出，CVE-2010-5139 ，黑客通过整数溢出构造了大概92233720368.54277039 个比特币，最近的SMT/BEC的整数安全场景与之前比特币的场景类似。

传统安全领域中，整数安全与数据模型和整数运算支持的运算符相关，其中数据模型又跟处理器架构体系和操作系统平台相关。如下图。

C中容易引发整数安全问题的运算符简要罗列如下。

Solidity合约中的整数安全场景与之类似。

1.2 Solidity中的整数安全场景

SMT和BEC都是以太坊代币生态下的一个普通的ERC-20代币。转账流通都是通过以太坊的solidity合约进行实现。

区块链1.0的比特币也有脚本语言，但是为了安全阉割掉了循环和递归等图灵完备性语言才有的功能。以太坊Solidity设计之初就被定位为图灵完备性语言。Solidity的图灵完备性也为后续的合约漏洞陆续埋下了伏笔，如The Dao漏洞事件直接导致以太坊硬分叉成了eth和旧链etc。

Solidity语言暂不支持类似于C中的float double等浮点型数据类型。支持int/uint变长的有符号或无符号整型。变量支持的步长以8递增，支持从uint8到uint256，以及int8到int256。需要注意的是，uint和int默认代表的是uint256和int256。uint8的数值范围与C中的uchar相同，即取值范围是0到2^8-1，uint256支持的取值范围是0到2^256-1，余下数据类型以此类推。

Solidity语言中对于运算符的支持如下。

比较：<=，<，==，!=，>=，>，返回值为bool类型。
位运算符：&，|，（^异或），（~非）。
数学运算：+，-，一元运算+，*，/，（%求余），（**平方）。

Solidity合约代码的逻辑都相对简单，运算符的使用中加法减法和乘法居多。

以太坊提供有一个Solidity语言的在线编译测试工具。http://remix.ethereum.org/#optimize=false&version=soljson-v0.4.23+commit.124ca40d.js 我们以加法和减法运算作为举例,简单说明下整数溢出在Solidity语言中的常规情况。

编写如下solidity测试代码。

pragma solidity ^0.4.0;
contract C {
// (2**256 – 1) + 1 = 0
function overflow() returns (uint256 _overflow) {
uint256 max = 2**256 – 1;
return max + 1;
}

// 0 – 1 = 2**256 – 1
function underflow() returns (uint256 _underflow) {
uint256 min = 0;
return min – 1;
}
}

在线测试工具中编译运行结果如下。

可以看到uint256当取最大整数值，上溢之后直接回绕返回值为0，uint256当取0下溢之后直接回绕，返回值为2^256-1。这是solidity中整数溢出场景的常规情况。

1.3 Solidity中的整数溢出缓解和SafeMath库

为了减少solidity合约开发中产生的安全问题，以太坊的官方开发博客陆续发布了一些与solidity开发安全相关的博文。在2017年8月6日单独发过一篇使用SafeMath库进行整数安全操作的文章<< SafeMath to protect from overflows >>。详见链接

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

/**
* @title SafeMath
* @dev Math operations with safety checks that throw on error
*/
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) {
// assert(b > 0); // Solidity automatically throws when dividing by 0
uint256 c = a / b;
// assert(a == b * c + a % b); // There is no case in which this doesn’t hold
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;
}
}

可以看到相关的可能产生溢出的操作都单独封装成函数，加入assert断言做判断避免溢出。调用SafeMath库的方法如下。

2 SMT合约中的整数安全问题简析

与大型软件或者操作系统动辄十万行甚至千万行代码不同，智能合约的代码行数通常不多，功能也不是很复杂。一起来看下SMT合约的相关代码。

SMT的合约地址是https://etherscan.io/address/0x55f93985431fc9304077687a35a1ba103dc1e081#code

问题存在于transferProxy()函数代码如下

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

直接溢出绕过代码检查导致可以构造巨大数量的smt代币并进行转账。

攻击者的恶意转账记录可以从如下链接进行看到。

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

3 BEC合约中的整数安全问题简析

BEC的合约地址是0xC5d105E63711398aF9bbff092d4B6769C82F793D，合约代码可以访问etherscan的如下网址进行查看https://etherscan.io/address/0xc5d105e63711398af9bbff092d4b6769c82f793d#code。代码一共是299行。

问题函数如下图。

可以看到batchTransfer函数中,语句balances[msg.sender] = balances[msg.sender].sub(amount)和balances[_receivers[i]] = balances[_receivers[i]].add(_value)中，调用Safemath库中的安全函数来完成加减操作，但是在第三行代码， 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数额的恶意转账。

攻击者的恶意转账记录，可以从如下链接看到https://etherscan.io/tx/0xad89ff16fd1ebe3a0a7cf4ed282302c06626c1af33221ebe0d3a470aba4a660f。

可以从代码totalSupply进行看到，bec代币总量共计才7 000 000 000枚。

但是攻击者通过溢出amount绕过后续require中的判定条件分别向两个地址恶意转账了 57,896,044,618,658,100,000,000,000,000,000,000,000,000,000,000,000,000,000,000.792003956564819968枚bec代币。

4 合约整数漏洞事件总结

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

360 Aegis实验室，专注区块链安全研究

参考链接:

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

https://zhuanlan.zhihu.com/p/35989258?utm_medium=social&utm_member=ZjZlYmQ1MGZkMjZjZmJkNTE4MGFmMmExZjA5NTM0NmE%3D&utm_source=wechat_session&wechatShare=1&from=timeline&isappinstalled=0

<<Secure Coding in C and C++>>