原创智能合约安全事故回顾分析：The Dao事件

Posted 2021-02-01 gzhlt

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

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，让用户主动去操作这个接口完成调用。因为合约主动调用本身就存在安全隐患，合约的权限大于所有人。