链闻ChainNews：
在传统的桌面windows攻防对抗领域，伴随着微软和合作伙伴对软件开发流程推行SDL规范，同时对安全投入的逐步加大，单一的封包超长和文件特定字段内容超长导致的溢出漏洞在一些大型软件里几乎绝迹。目前，零星剩下了一些整数类的漏洞。如去年的nginxcve-2017-7529。而区块链方向，比较早的整数溢出类漏洞可追溯到2010年的比特币大整数溢出，CVE-2010-5139，黑客通过整数溢出构造了大概92233720368
?//0-1=2**256-1functionunderflow()returns(uint256_underflow){uint256min=0;returnmin-1;}}
专家：SMT和BEC所犯错误很低级，影响有限:YEE创始人、前百度移动安全总经理张磊及其团队认为，此次SMT发生的安全问题，和此前BEC发生的安全问题系出同源。张磊还表示，该问题虽影响巨大，但解决起来很简单，不会对行业造成太大影响。腾讯区块链技术专家屠海涛认为，这类安全问题只要交易所及时停止充提，影响就很小，只是个别币种受影响。[2018/4/25]
在线测试工具中编译运行结果如下。
可以看到uint256当取最大整数值，上溢之后直接回绕返回值为0，uint256当取0下溢之后直接回绕，返回值为2^256-1。这是solidity中整数溢出场景的常规情况。
1
火币Pro暂停SMT交易的公告:火币Pro发布公告称，应SmartMesh(SMT)项目方的要求，火币Pro暂停SMT/USDT、SMT/BTC和SMT/ETH的交易，具体开放时间另行通知。[2018/4/25]
functiondiv(uint256a,uint256b)internalconstantreturns(uint256){//assert(b>0);//Solidityautomaticallythrowswhendividingby0uint256c=a/b;//assert(a==b*ca%b);//Thereisnocaseinwhichthisdoesn'tholdreturnc;}
functionsub(uint256a,uint256b)internalconstantreturns(uint256){assert(b<=a);returna-b;}
functionadd(uint256a,uint256b)internalconstantreturns(uint256){uint256c=ab;assert(c>=a);returnc;}}
可以看到相关的可能产生溢出的操作都单独封装成函数，加入assert断言做判断避免溢出。调用SafeMath库的方法如下。
2.SMT合约中的整数安全问题简析
与大型软件或者操作系统动辄十万行甚至千万行代码不同，智能合约的代码行数通常不多，功能也不是很复杂。一起来看下SMT合约的相关代码。
SMT与RDN合作推出SmartRaiden:今日SmartMesh官方推特发布，SmartMesh (SMT)和Raiden Network Token (RDN)合作推出了SmartRaiden开源技术，SmartRaiden 是移动版雷电网络，有助于提高SmartMesh 系统的功能和可扩展性。[2018/4/17]
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=balances.sub(amount)和balances]=balances].add(_value)中，调用Safemath库中的安全函数来完成加减操作，但是在第三行代码，uint256amount=uint256(cnt)*_value却直接使用乘法运算符。
其中变量cnt为转账的地址数量，可以通过外界的用户输入_receivers进行控制，_value为单地址转账数额，也可以直接进行控制。乘法运算溢出，产生了非预期amount数值，并且外界可以通过调整_receivers和_value的数值进行操控。紧接着下面有一句对amount进行条件检查的代码require(_value>0&&balances>=amount)；其中balances代表当前用户的余额。amount代表要转的总币数。代码意思为确保当前用户拥有的代币余额大于等于转账的总币数才进行后续转账操作。因为通过调大单地址转账数额_value的数值，amount溢出后可以为一个很小的数字或者0，很容易绕过balances>=amount的检查代码。从而产生巨大_value数额的恶意转账。
攻击者的恶意转账记录，可以从如下链接看到https://etherscan.io/tx/0xad89ff16fd1ebe3a0a7cf4ed282302c06626c1af33221ebe0d3a470aba4a660f。
可以从代码totalSupply进行看到，bec代币总量共计才7000000000枚。
但是攻击者通过溢出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开发人员投入更多时间和精力，确保合约的安全性。
参考链接:https://ethereumdev.io/safemath-protect-overflows/https://zhuanlan.zhihu.com/p/35989258?utm_medium=social&utm_member=ZjZlYmQ1MGZkMjZjZmJkNTE4MGFmMmExZjA5NTM0NmE=&utm_source=wechat_session&wechatShare=1&from=timeline&isappinstalled=0
更多精彩内容，关注链闻ChainNews公众号，或者来微博@链闻ChainNews与我们互动！转载请注明版权和原文链接！
来源链接：www.8btc.com
本文来源于非小号媒体平台：
链闻研究院
现已在非小号资讯平台发布1篇作品，
非小号开放平台欢迎币圈作者入驻
入驻指南：
/apply_guide/
本文网址：
/news/3626905.html
免责声明：
1.资讯内容不构成投资建议，投资者应独立决策并自行承担风险
2.本文版权归属原作所有，仅代表作者本人观点，不代表非小号的观点或立场
下一篇：
文摘|确保加密货币安全的十条戒律
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。