ALL:以太坊智能合约为何安全漏洞频发?

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

概述

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

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

逻辑问题?

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

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

合约代码问题?

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

1.重入

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

function?withdrawEther()?public?{uint?amount?=?userBalances;bool?success,?)?=?msg

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

发生在2016年6月,著名的TheDAO攻击,从而导致了ETC分叉的事件,就是通过同样的方法实施攻击的。从事后看来,这只是一个小小的程序问题。要修复这个问题也非常容易,只需要将两行代码调换顺序即可:

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

2.让你的交易不打包

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

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

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

3.错误使用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的控制权,从而完成攻击。

4.溢出攻击

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

5.fallback?可以revert

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

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

function?()?public?payable?{???revert?()?;?}

6.?selfdestruct可以定义任意受益者,而不会调用fallback

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

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

7.?未正确使用delegatecall

在使用delegatecall时,要注意上下文的变化。用call进行合约调用时,上下文被切换至被调用合约。而用delegatecall进行合约调用时,上下文依然在本合约。

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

8.不同方法传气不一样

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

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

结语

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

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

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

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

链链资讯

[0:4ms0-3:971ms