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

发表于:2018-4-24 09:54

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:爬虫    来源:知乎专栏

#
Bug
#
代码
#
黑客
  现在进入你还是先行者,最后观望者进场才是韭菜。
  背景

  今天有人在群里说,Beauty Chain 美蜜 代码里面有bug,已经有人利用该bug获得了 57,896,044,618,658,100,000,000,000,000,000,000,000,000,000,000,000,000,000,000.792003956564819968 个 BEC
  那笔操作记录是 0xad89ff16fd1ebe3a0a7cf4ed282302c06626c1af33221ebe0d3a470aba4a660f

  下面我来带大家看看,黑客是如何实现的!
  我们可以看到执行的方法是 batchTransfer
  那这个方法是干嘛的呢?(给指定的几个地址,发送相同数量的代币)
  整体逻辑是
  你传几个地址给我(receivers),然后再传给我你要给每个人多少代币(value)
  然后你要发送的总金额 = 发送的人数* 发送的金额
  然后 要求你当前的余额大于 发送的总金额
  然后扣掉你发送的总金额
  然后 给receivers 里面的每个人发送 指定的金额(value)
  从逻辑上看,这边是没有任何问题的,你想给别人发送代币,那么你本身的余额一定要大于发送的总金额的!
  但是这段代码却犯了一个很傻的错!
  代码解释

  这个方法会传入两个参数
  1._receivers
  2._value
  _receivers 的值是个列表,里面有两个地址
  0x0e823ffe018727585eaf5bc769fa80472f76c3d7
  0xb4d30cac5124b46c2df0cf3e3e1be05f42119033
  _value 的值是 8000000000000000000000000000000000000000000000000000000000000000
  我们再查看代码(如下图)

  我们一行一行的来解释
  uint cnt = _receivers.length;
  是获取 _receivers 里面有几个地址,我们从上面可以看到 参数里面只有两个地址,所以 cnt=2,也就是 给两个地址发送代币
  uint256 amount = uint256(cnt) * _value;
  uint256
  首先 uint256(cnt) 是把cnt 转成了 uint256类型
  那么,什么是uint256类型?或者说uint256类型的取值范围是多少...
  uintx 类型的取值范围是 0 到 2的x次方 -1
  也就是 假如是 uint8的话
  则 uint8的取值范围是 0 到 2的8次方 -1
  也就是 0 到255
  那么uint256 的取值范围是
  0 - 2的256次方-1 也就是 0 到115792089237316195423570985008687907853269984665640564039457584007913129639935
  python 算 2的256次方是多少

  那么假如说 设置的值超过了 取值范围怎么办?这种情况称为 溢出
  举个例子来说明
  因为uint256的取值太大了,所以用uint8来 举例。。。
  从上面我们已经知道了 uint8 最小是0,最大是255
  那么当我 255 + 1 的时候,结果是啥呢?结果会变成0
  那么当我 255 + 2 的时候,结果是啥呢?结果会变成1
  那么当我 0 - 1 的时候,结果是啥呢?结果会变成255
  那么当我 0 - 2 的时候,结果是啥呢?结果会变成254
  那么 我们回到上面的代码中,
  amount = uint256(cnt) * _value
  则 amount = 2* _value
  但是此时 _value 是16进制的,我们把他转成 10进制
  (python 16进制转10进制)

  可以看到 _value = 57896044618658097711785492504343953926634992332820282019728792003956564819968
  那么amount = _value*2 = 115792089237316195423570985008687907853269984665640564039457584007913129639936
  可以在查看上面看到 uint256取值范围最大为 115792089237316195423570985008687907853269984665640564039457584007913129639935
  此时,amout已经超过了最大值,溢出 则 amount = 0
  下一行代码 require(cnt > 0 && cnt <= 20); require 语句是表示该语句一定要是正确的,也就是 cnt 必须大于0 且 小于等于20
  我们的cnt等于2,通过!
  require(_value > 0 && balances[msg.sender] >= amount);
  这句要求 value 大于0,我们的value是大于0 的 且,当前用户拥有的代币余额大于等于 amount,因为amount等于0,所以 就算你一个代币没有,也是满足的!
  balances[msg.sender] = balances[msg.sender].sub(amount);
  这句是当前用户的余额 - amount
  当前amount 是0,所以当前用户代币的余额没有变动
  for (uint i = 0; i < cnt; i++) {
  balances[_receivers[i]] = balances[_receivers[i]].add(_value);
  Transfer(msg.sender, _receivers[i], _value);
  }
  这句是遍历 _receivers中的地址, 对每个地址做以下操作
  balances[_receivers[i]] = balances[_receivers[i]].add(_value); _receivers中的地址 的余额 = 原本余额+value
  所以 _receivers 中地址的余额 则加了57896044618658097711785492504343953926634992332820282019728792003956564819968 个代币!!!
  Transfer(msg.sender, _receivers[i], _value); } 这句则只是把赠送代币的记录存下来!!!
  总结
  就一个简单的溢出漏洞,导致BEC代币的市值接近归0
  那么,开发者有没有考虑到溢出问题呢?
  其实他考虑了,

  可以看如上截图
  除了amount的计算外, 其他的给用户转钱 都用了safeMath 的方法(sub,add)
  那么 为啥就偏偏这一句没有用safeMath的方法呢。。。
  这就要用写代码的人了。。。
  啥是safeMath

  safeMath 是为了计算安全 而写的一个library
  我们看看他干了啥?为啥能保证计算安全.
  function mul(uint256 a, uint256 b) internal constant returns (uint256) {
  uint256 c = a * b;
  assert(a == 0 || c / a == b);
  return c;
  }
  如上面的乘法. 他在计算后,用assert 验证了下结果是否正确!
  如果在上面计算 amount的时候,用了 mul的话, 则 c / a == b 也就是 验证 amount / cnt == _value
  这句会执行报错的,因为 0 / cnt 不等于 _value
  所以程序会报错!
  也就不会发生溢出了...
  那么 还有一个小问题,这里的 assert 好 require 好像是干的同一件事
  都是为了验证 某条语句是否正确!
  那么他俩有啥区别呢?
  用了assert的话,则程序的gas limit 会消耗完毕
  而require的话,则只是消耗掉当前执行的gas
  总结
  那么 我们如何避免这种问题呢?
  我个人看法是
  1.只要涉及到计算,一定要用safeMath
  2.代码一定要测试
  3.代码一定要review!
  4.必要时,要请专门做代码审计的公司来 测试代码
  这件事后需要如何处理呢?
  目前,该方法已经暂停了(还好可以暂停)所以看过文章的朋友 不要去测试了...

  不过已经发生了的事情咋办呢?
  我能想到的是,快照在漏洞之前,所有用户的余额情况
  然后发行新的token,给之前的用户 发送等额的代币...
  写了个爬虫,爬取热门ICO的源代码
  里面有没有bug,自己找吧~
   https://github.com/jin10086/ico-spider

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号