收藏(0)

首先需要说明的一点是,这个世界上没有绝对安全的技术。在区块链发展的十年里,各种基于区块链的数字货币引发的安全事故层出不穷,这些安全威胁主要来源有三个方面:

  1. 自身安全机制的问题,类似智能合约。
  2. 生态安全问题,交易所,矿池,网站等等。
  3. 使用者安全问题,包括个人账号密码的泄露,被钓鱼等。

作为普通的开发人员或者有一定编程知识的从业人员,我们首先应该确保的是自身安全机制没有问题,当然这个“没有问题”是一个相对的概念。智能合约的安全为什么这么重要,这很大原因在于智能合约编程和传统编程的巨大区别:

  1. 智能合约本身开发简单,但是却能够存储几千万到几十亿的的资产。
  2. 智能合约部署的过程是一次共识的过程,如果部署以后发现了安全问题,不能通过传统的打补丁或者升级的方式来避免。必须在设计和编码的过程中处理好这些容错和异常终止逻辑。
  3. 智能合约的代码都是开放的,多任何人可见。这其中就包括了一些不怀好意的黑客,没有传统开发过程中的加密,访问控制。

本系列希望通过对过往发生的一些安全事故的回顾,来提醒或者说警醒各位开发者,在开发的过程中,即便不能做到百分百安全,那么起码能做到“吸取前人的教训”,避免已经发生过的安全事故再次发生。

本文介绍的是对以太坊影响深远的The Dao 智能合约漏洞事件

事件介绍

The Dao 是一个去中心化的自治风险投资基金,通过发布的智能合约来募集资金,参与者可以通过投票的方式来投资以太坊上的应用,如果盈利,参与者就能获得回报。2016年6月17日,一名黑客发现了The Dao募资合约的漏洞,使得他可以无限的从合约中转出资金,短短几小时,360万的以太币被转出。这件事对以太坊的发展产生了巨大的影响,最后为了弥补用户的损失V神智能采用软分叉的方式,即所有通过这个The Dao的合约来减少新增用户余额的方式都被视为无效。

漏洞原因

首先请读者看一下合约中的代码,这端代码的业务逻辑是:如果用户不同意其他用户的投票,可以选择分裂出去。简单的说就是用户拿钱给基金会投资,中间用户如果反悔可以随时退钱。

//用户选择分裂出去调用的函数

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执行任何操作,包括重新调用原合约的接口。本次攻击的黑客正式利用了这一点。

攻击手段
  1. 黑客先是通过自己创建了一个合约Child Dao,这个合约拥有一个回调函数,这个函数的作用就是去调用The Dao中的splitDao。
  2. 黑客提交了splitDao,地址是Child Dao的地址,当然在此之前的操作都是合法的操作,满足The Dao定义的调用splitDao的条件。
  3. 结合上面的代码,你会发现,开发者的代码先是在函数withdrawRewardFor中把金额退还给了用户,然后在退出函数之后将用户的余额置为0。那么如果攻击者在withdrawRewardFor和余额置空之间在此调用withdrawRewardFor,将会再次向攻击者提交的地址转移账户金额。结合刚才介绍的call函数知识点,聪明的读者应该能够想到攻击的原理了。黑客利用了call函数的机制,在合约中再次调用转账申请,由于上一次转账申请的余额还没有更新,所以第二次也会成功。相当于在循环中的重复调用自己,编程中的递归。
如何防范

其实The Dao的开发者的漏洞代码在传统的编程中没有任何问题,传统编程为了应对事务处理的结果,往往在转账之后进行余额的更新,因为有可能因为网络等原因导致转账不成功,如果程序提前把用户的账户余额置为0则容易引发数据丢失的问题。本次The Dao事件的代码修复可以从多方面来考虑:

  1. 调整代码顺序,在转账之前执行余额减扣。
  2. 避免不可控的函数调用,黑客利用call函数fallback的调用机制来攻击,这个场景其实在很多别的攻击事件中也可能发生,后面介绍的DOS攻击中黑客也利用了这一点。一方面应该避免这种方式调用,其实还应该避免在合约中直接使用转账操作,可以在设计的时候提供一个转账mapping,每个用户可以提现金额的多少对应其中的key value,让用户主动去操作这个接口完成调用。因为合约主动调用本身就存在安全隐患,合约的权限大于所有人。

作者简介

Figo:Blockgeek签约技术作者,区块链重度爱好者。热衷于区块链技术推广,参与hyperledger fabric中文社区翻译,对以太坊,EOS,HPB,星云等各大公链有深入研究。

仅一条评论

请输入你的评论!
请在这里输入您的名字