freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

LightCoin合约非一致性检查漏洞分析
2018-07-17 10:00:25

*本文中涉及到的相关漏洞已报送厂商并得到修复,本文仅限技术研究与讨论,严禁用于非法用途,否则产生的一切后果自行承担。

0x00 项目简述

LIGHT (光链) 是世界上第一个双层区块链(父链与子链)。其中,LIGHT 父链与传统的公链类似,有且仅有一个,保证记录完整、透明、不可被篡改或销毁。LIGHT子链可以是多个且相互独立存在,基于PoM validation方式,结合In-Memory数据库缓存,有效提高缓存环节吞吐量,QPS可达10万以上,实现性能大幅提高。LIGHT突破性地解决了当今数字货币在交易时处理速度严重滞后的问题,实现瞬时完成实时交易。

0x01 漏洞详情

合约地址:

0xd97579Cea3fE2473682a4C42648134BB982433B9

合约代码地址:

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

合约类型:ERC20(https://github.com/ethereum/EIPs/issues/20

漏洞函数:transferFrom

漏洞类型:非一致性检查

漏洞危害:可导致绕过授权额度检查,转出超出授权额度代币至任意以太坊账户。

0x02 细节分析

image.png

代码55行在检查授权转账额度是没有问题的,但是在58行减掉已转出的授权额度时,错误的写成了allowed[_from][_to] -= _value。该行代码导致在授权转账完成后,限额依然不变,在下一次操作授权转账时,依然可以继续按照原本限额转出代币。该漏洞属于一个逻辑漏洞,由于校验的条件和操作的条件不一致,导致后续绕过校验。

该漏洞逻辑如图所示。

image.png

0x03 漏洞调试

我们使用Remix调试代码,调试的时候我们修改24行为本地Javascript VM的钱包地址,点Deloy部署后,和合约为合约部署者分配2000000个Token。首先调用approve函数为Javascript VM的另外一个账户授权一点转账额度。调用参数如下。该调用为参数1地址授权10000额度的转账权限。

"0x14723a09acff6d2a60dcdf7aa4aff308fddc160c",10000

调用完毕后,我们切换到授权过的这个账户(既第一个参数),调用transferFrom函数进行授权转账测试。调用参数如下,该调用正确情况下,应该由参数1账户转向参数2账户9999个Token。同时减除调用者授权额度9999。

"0xca35b7d915458ef540ade6068dfe2f44e8fa733c","0x4b0897b0513fdc7c541b6d9d7e929c4e5364d2db",9999

由于remix不支持查看二级字典的调试功能,为了调试方便我们在59行后加一行var test =allowed[_from][msg.sender]便于我们观察变量的更新情况。调试结果如下图。我们可以看到,转账成功了,但是allowed[_from][msg.sender]的值却并没有变,正确情况下该值应该等于10000-9999。

image.png使用相同参数再次调用一下transferFrom,我们会发现,转账仍然会成功,调用结果如下。

image.png

0x04修复建议

将58行改为:

allowed[_from][msg.sender] -= _value;

*本文作者莫良@BYSEC.IO,转载请注明来自FreeBuf.COM

本文作者:, 转载请注明来自FreeBuf.COM

# 漏洞 # 数据库 # 区块链 # 数字货币
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者