DeFi 安全事件为何频发？梳理以太坊智能合约常见漏洞

以太坊智能合约的安全问题主要是因为其「过于灵活」引起的，灵活性和安全性如同天平的两端。

原文标题：《以太坊智能合约为何安全漏洞频发？》
撰文：谈国鹏，Ownbit 创始人

最近，随着 DeFi 火热，以太坊智能合约安全漏洞频发。究竟是什么原因造成的，以及如何更好地防范这些漏洞？

概述

相比于比特币而言，以太坊更易发生安全事故。这主要是因为以太坊虚拟机是图灵完备的，以太坊可实现函数间相互调用、嵌套调用，智能合约间相互调用等各种复杂逻辑。而比特币只实现了基于栈的非图灵完备的虚拟机，并只能通过操作码进行入栈和出栈操作。另外比特币也没有复杂的 DApp 应用，所以逻辑上简单，故而没有太多空间引发安全漏洞。

以太坊上各种 DApp 复杂的智能合约逻辑是引发安全漏洞的主因。以太坊智能合约的安全漏洞主要可以分为逻辑问题和合约代码问题两种。

逻辑问题

最近频繁的「闪电贷」攻击是一个典型的逻辑问题引起的安全漏洞。在各种闪电贷攻击中你可以看到清晰的逻辑问题。攻击者只要制造出两个系统之间的价格差，便能通过闪电贷攻击获利。

闪电贷攻击的逻辑细节大家可以阅读之前一篇专门讲闪电贷的文章：「造富神器」闪电贷。本文主要阐述合约代码问题。

合约代码问题

我们知道，几乎稍微复杂一点的代码都或多或少地存在问题（bug）。了解出现问题的原因，并且归纳问题类别可以帮助我们更好地防范它们。下面是 Ownbit 钱包团队整理的关于以太坊智能合约安全最容易出现问题的点。

重入（Reentrancy）

这是排名第一的问题。所谓「重入」就是一个方法被多次循环调用。而这通常是合约开发者所意想不到的。例如一个取款合约：

function withdrawEther() public {
    uint amount = userBalances[msg.sender];
    (bool success, ) = msg.sender.call.value(amount)(""); // 这里重入
    require(success);
    userBalances[msg.sender] = 0;
}   

这是一段很简单的取款合约，让用户取走他的 ETH 余额。开发者并没有意识到这段代码可能会被重入。方法是：只要调用者是一个合约账户，那么 msg.sender.call 将默认调用该合约账户的 fallback 函数。攻击者只需要在其 fallback 函数再次调用 withdrawEther 就可以源源不断地取走 ETH。

发生在 2016 年 6 月，著名的 The DAO 攻击，从而导致了 ETC 分叉的事件，就是通过同样的方法实施攻击的。从事后看来，这只是一个小小的程序问题（却造成了如此严重的后果）。要修复这个问题也非常容易，只需要将两行代码调换顺序即可：

 userBalances[msg.sender] = 0;
 (bool success, ) = msg.sender.call.value(amount)(""); 

让你的交易不打包

以太坊区块的打包机制是按照给予的矿工费（GasPrice）进行优先打包，并且每个区块有总 GasLimit 的限制（目前为每区块 1200 万 Gas）。所以攻击者可以制造出若干使用 GasLimit 非常大，并且 GasPrice 给得非常高的交易，让它们优先占满区块，从而让目标交易无法被打包。

所以，在编写合约逻辑时，不能假设你的交易会在有限时间内被打包，否则就容易受到此类攻击。著名的「Fomo3D」事件就是用了这样的攻击方法。

Fomo3D 游戏规则是奖励最后一个购得某个商品的人。每次商品被买入将重置该商品的定时器，如果在定时器达到 0 之前没有其他购买者，则你将获得系统的奖励。攻击者在 Fomo3D 中买入商品，然后同时发送大量占用区块的攻击交易，以至于在接下来的 13 个区块内，其他购买者的交易无法被打包。这时定时器达到 0，并认为无其他购买者。攻击者便获得了奖励，完成了攻击。

错误使用 tx.origin

如果你发现一个合约使用了 tx.origin，那么可以留心一下此处可能存在的漏洞。在大部分情况下，我们应该使用 msg.sender 来替代 tx.origin，因为使用 tx.origin 容易引发安全漏洞。

很多时候，合约开发人员会假定 msg.sender 和 tx.origin 是相等的，但其实不是。例如：用户 A 调用 合约 B，而合约 B 进一步调用 合约 C，那么在合约 B 和 C 中 tx.origin 都将是 A，而 msg.sender 则一个是 A，一个是 B。

一般攻击者会引诱 A 调用一个诱导合约 B，而 B 再去调用由 A 部署的目标合约 C，因为 合约 C 错误地使用了 tx.origin，合约 B 可以通过传递过来的 tx.origin 获得对 合约 C 的控制权，从而完成攻击。

溢出攻击

智能合约里的数据是可能溢出的，例如：uint256，你觉得很大：2^256。它的确很大，但依然可以溢出。例如一个合约允许对一个数据进行加减，攻击可以通过对这个数据进行精心策划的调用，让其通过溢出达到允许执行某些逻辑的目的，从而实现攻击。

fallback 可以 revert

fallback 是可以 revert 的，就是说，你如果向对方转移 ether，对方可以让你总是不成功。

例如你编写一段合约，并且依赖于你成功向某个地址转移 ether，那么攻击可以部署一个合约，将其 fallback 写成 revert 来让你来的调用总是失败：

function () public payable {
   revert () ; 
}

selfdestruct 可以定义任意受益者，而不会调用 fallback

当你以为可以通过 revert 进行阻止所有人向你付款 ether 时，你可能又错了。攻击者通过创建一个合约，并且然后销毁这个合约。销毁合约以太坊将退还一部分 ether 作为鼓励，而这个退还可以指定任意受益者，而对方的 fallback 函数不会被调用。

这就是说，开发者要意识到你没有办法完全阻止别人向你的合约账户转移 ether。

未正确使用 delegatecall

在使用 delegatecall 时，要注意上下文（即 msg.sender 等）的变化。用 call 进行合约调用时，上下文被切换至被调用合约。而用 delegatecall 进行合约调用时，上下文依然在本合约。

delegatecall 和 call 不同的调用上下文也是合约安全漏洞较常出现的地方。

不同方法传气不一样

当我们进行 ether 转移时，不同的方法传气（Gas）不一样。使用 send() 和 transfer() 传递气仅为 2300，而使用 call.value()() 则将剩余的气全部传递。因此，最新的安全规范是建议使用 call 而不是 send 或者 transfer 进行 ether 转移。

如果你发现一个合约还是使用 send 或者 transfer，那么你可以制造出目标合约，让其转移 Out of Gas。

结语

以上这些点是合约代码最常出现问题的点。每个错误的原因都比较原子化，理解相应的原理可以帮助我们有效地避免这些问题。当合约逻辑复杂时，一定会有更加复杂、隐藏得更深的逻辑问题，这时，这些原子点的检查依然可以帮助我们找到它们。

以太坊智能合约的安全问题主要是因为其「过于灵活」引起的。灵活性和安全性如同天平的两端。以太坊选择了灵活性，某种程度上便把安全性的潜在风险留给了市场。

一个 DeFi 项目能否安全稳定地运行，或是会被黑客攻击，取决于合约开发人员对原理的理解、对细节的把控，以及严肃认真的态度。线上合约犯错的代价是巨大的，这就对合约开发人员提出了更高的要求！

来源链接：mp.weixin.qq.com