关于 Edgeware 锁仓合约的拒绝服务漏洞

关于 Edgeware 锁仓合约的拒绝服务漏洞,我们注意到 Edgeware 被爆了个严重的漏洞,这个漏洞已经修复,对已经锁仓的用户及修复后继续锁仓的用户不存在影响,且目前的情况来看,由于漏洞是负责任披露,应该是没有造成实际影响。

但这个漏洞为什么说严重?我简单科普下。

近期,Edgeware 这个 Polkadot 生态知名的链项目,因为独创的 ILO(Initial Lock-up Offering) 机制,其中一种方式是允许参与方通过锁仓 ETH 来获取更多的 Edgeware 数字货币激励,已经处理了超过 9 亿美元的 ETH 并锁定了超过 2.9 亿美元,一度很火热。

图1

如“图 1”所示,每个参与者都可以通过 Edgeware 发布在以太坊上的 Lockdrop 合约进行锁仓获取激励操作,成功后会生成一份属于自己权限控制下的独立 Lock 合约,这份合约本身是安全的(至少我们还未发现已知潜在风险)。但有趣的是:漏洞出现在 Lock 合约生成的那一刻。

图2

大家注意“图 2”的 lock 函数,有一段关键代码:

assert(address(lockAddr).balance == msg.value);

这段代码做了强制判断:属于参与者的 Lock 合约的金额必须等于参与者锁仓时发送的金额,如果不等于,意味着 lock 失败,这个失败会导致参与者的 Lock 合约“瘫痪”而形成“拒绝服务”,直接后果就是:假如攻击持续着,Edgeware 这个 Lockdrop 机制将不再可用。但这个漏洞对参与者的资金无影响。那么,什么情况下会导致“address(lockAddr).balance 不等于 msg.value”?攻击者如果能提前推测出参与者的 Lock 合约地址就行(这在以太坊黄皮书里有明确介绍),此时攻击者只需提前往参与者的 Lock 合约地址随便转点 ETH 就好。Edgeware 针对这个漏洞的修复代码也很简单,见“图 3”,将 Lockdrop 合约的:

图3

assert(address(lockAddr).balance == msg.value);

改为:

assert(address(lockAddr).balance >= msg.value);

就这样。是的,Lockdrop 合约重新发布了一份新的。

存在漏洞的 Lockdrop 合约: https://etherscan.io/address/0x1b75b90e60070d37cfa9d87affd124bb345bf70a#contracts

修复后的 Lockdrop 合约: https://etherscan.io/address/0xFEC6F679e32D45E22736aD09dFdF6E3368704e31#contracts

智能合约真是一点错误都不行。相关参考:

https://medium.com/@nmcl/gridlock-a-smart-contract-bug-73b8310608a9 https://blog.edgewa.re/a-denial-of-service-bug-in-the-edgeware-lockdrop https://ethereum.github.io/yellowpaper/paper.pdf