【转载】智能合约安全事故回顾分析(1):The Dao事件
首先需要说明的一点是,这个世界上没有绝对安全的技术。在区块链发展的十年里,各种基于区块链的数字货币引发的安全事故层出不穷,这些安全威胁主要来源有三个方面:
-
自身安全机制的问题,类似智能合约。
-
生态安全问题,交易所,矿池,网站等等。
-
使用者安全问题,包括个人账号密码的泄露,被钓鱼等。
作为普通的开发人员或者有一定编程知识的从业人员,我们首先应该确保的是自身安全机制没有问题,当然这个“没有问题”是一个相对的概念。智能合约的安全为什么这么重要,这很大原因在于智能合约编程和传统编程的巨大区别:
-
智能合约本身开发简单,但是却能够存储几千万到几十亿的的资产。
-
智能合约部署的过程是一次共识的过程,如果部署以后发现了安全问题,不能通过传统的打补丁或者升级的方式来避免。必须在设计和编码的过程中处理好这些容错和异常终止逻辑。
-
智能合约的代码都是开放的,多任何人可见。这其中就包括了一些不怀好意的黑客,没有传统开发过程中的加密,访问控制。
本系列希望通过对过往发生的一些安全事故的回顾,来提醒或者说警醒各位开发者,在开发的过程中,即便不能做到百分百安全,那么起码能做到“吸取前人的教训”,避免已经发生过的安全事故再次发生。
本文介绍的是对以太坊影响深远的The Dao 智能合约漏洞事件。
事件介绍
The Dao 是一个去中心化的自治风险投资基金,通过发布的智能合约来募集资金,参与者可以通过投票的方式来投资以太坊上的应用,如果盈利,参与者就能获得回报。2016年6月17日,一名黑客发现了The Dao募资合约的漏洞,使得他可以无限的从合约中转出资金,短短几小时,360万的以太币被转出。这件事对以太坊的发展产生了巨大的影响,最后为了弥补用户的损失V神智能采用软分叉的方式,即所有通过这个The Dao的合约来减少新增用户余额的方式都被视为无效。
漏洞原因
首先请读者看一下合约中的代码,这端代码的业务逻辑是:如果用户不同意其他用户的投票,可以选择分裂出去。简单的说就是用户拿钱给基金会投资,中间用户如果反悔可以随时退钱。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
//用户选择分裂出去调用的函数 function splitDAO( uint _proposalID, address _newCurator) noEther onlyTokenholders returns ( bool _success) { // ... //利用平衡数组计算应该转移多少代币 p是提案对象 uint fundsToBeMoved = (balances[msg.sender] * p.splitData[0].splitBalance) / p.splitData[0].totalSupply; if (p.splitData[0].newDAO.createTokenProxy.value(fundsToBeMoved)(msg.sender) == false ) throw ; // ... // Burn DAO Tokens Transfer(msg.sender, 0, balances[msg.sender]); withdrawRewardFor(msg.sender); // 转移对应的金额给用户 // XXXXX Notice the preceding line is critically before the next few totalSupply -= balances[msg.sender]; // 相应变量更新 balances[msg.sender] = 0; // 余额置为0 paidOut[msg.sender] = 0; return true ; } function withdrawRewardFor(address _account) noEther internal returns( bool _success) { if ((balanceOf(_account) * rewardAccount.accumulatedInput()) / totalSupply < paidOut[_account]) throw ; uint reward = (balanceOf(_account) * rewardAccount.accumulatedInput()) / totalSupply - paidOut[_account]; if (!rewardAccount.payOut(_account, reward)) // XXXXX vulnerable throw ; paidOut[_account] += reward; return true ; } function payOut(address _recipient, uint _amount) returns ( bool ) { if (msg.sender != owner || msg.value > 0 || (payOwnerOnly && _recipient != owner)) throw ; if (_recipient.call.value(_amount)()) { // XXXXX vulnerable PayOut(_recipient, _amount); return true ; } else { return false ; } } |
上面的代码在了解业务很容易明白:
用户提出分裂--》合约计算应该退给用户的金额--》调用call函数发送金额给用户--》用户的账户余额归为0,即先是调用splitDAO,splitDao中调用withdrawRewardFor,withdrawRewardFor中调用payOut执行转账。
乍一看没什么问题,讲述黑客的攻击手段之前,回顾一下solidity编程中的知识点:如果call函数的调用结果是true就一定是执行成功的吗?答案是NO,因为有可能是执行了回调函数。当调用call.value的时候,会把所有的gas发送到合约地址上并执行默认函数。所以这个默认函数将会有足够的gas执行任何操作,包括重新调用原合约的接口。本次攻击的黑客正式利用了这一点。
攻击手段
-
黑客先是通过自己创建了一个合约Child Dao,这个合约拥有一个回调函数,这个函数的作用就是去调用The Dao中的splitDao。
-
黑客提交了splitDao,地址是Child Dao的地址,当然在此之前的操作都是合法的操作,满足The Dao定义的调用splitDao的条件。
-
结合上面的代码,你会发现,开发者的代码先是在函数withdrawRewardFor中把金额退还给了用户,然后在退出函数之后将用户的余额置为0。那么如果攻击者在withdrawRewardFor和余额置空之间在此调用withdrawRewardFor,将会再次向攻击者提交的地址转移账户金额。结合刚才介绍的call函数知识点,聪明的读者应该能够想到攻击的原理了。黑客利用了call函数的机制,在合约中再次调用转账申请,由于上一次转账申请的余额还没有更新,所以第二次也会成功。相当于在循环中的重复调用自己,编程中的递归。
如何防范
其实The Dao的开发者的漏洞代码在传统的编程中没有任何问题,传统编程为了应对事务处理的结果,往往在转账之后进行余额的更新,因为有可能因为网络等原因导致转账不成功,如果程序提前把用户的账户余额置为0则容易引发数据丢失的问题。本次The Dao事件的代码修复可以从多方面来考虑:
-
调整代码顺序,在转账之前执行余额减扣。
-
避免不可控的函数调用,黑客利用call函数fallback的调用机制来攻击,这个场景其实在很多别的攻击事件中也可能发生,后面介绍的DOS攻击中黑客也利用了这一点。一方面应该避免这种方式调用,其实还应该避免在合约中直接使用转账操作,可以在设计的时候提供一个转账mapping,每个用户可以提现金额的多少对应其中的key value,让用户主动去操作这个接口完成调用。因为合约主动调用本身就存在安全隐患,合约的权限大于所有人。