【链安】竞态条件漏洞分析及详细修复建议

什么是竞态条件

【竞态条件】竞态条件的官方定义是如果程序的执行顺序改变会影响结果,它就属于一个竞态条件。
在智能合约中,竞态条件漏洞被攻击者利用后,攻击者利用一个与存在漏洞合约平起平坐的外部合约竞争夺取控制权,改变该智能合约的行为。
用一个形象的比喻来说明,将智能合约理解成一条高速公路,所有函数和功能理解为车辆,原本的执行顺序规定了车辆经过的顺序,此时一名熟练的老司机,驾驶着GTR在弯道超车加塞,扰乱了整个道路的秩序,抢占了在道路中的领先地位,进而为所欲为,戏耍合约规则。
以太坊智能合约的特点之一是能够调用和利用其它外部合约的代码,调用外部合约主要存在的危险就是外部合约可以接管控制流,并对调用函数不期望的数据进行更改。这类漏洞有多种形式,我们在这里深度解析重入和交易顺序依赖两种。

1. 重入漏洞(Reentrancy)

• 问题描述

合约通常用来处理 Ether,因此通常会将 Ether 发送给各种外部用户地址。调用外部合约或将以太网发送到地址的操作需要合约提交外部调用。这些外部调用可能被攻击者劫持,迫使合约执行进一步的代码(即通过回退函数),包括回调自身。因此代码执行"重新进入"合约。这种攻击被用于上述臭名昭著的DAO 攻击。

我们把存在漏洞的合约简化成如下案例合约:

该合约有两个函数:depositFunds()和withdrawFunds(),depositFunds()的功能是增加msg.sender的余额,withdrawFunds()的功能是取出msg.sender指定的数值为_weiToWithdraw的Ether。

现在,一个攻击者创建了下列合约:

PS:注意此处由于重入攻击造成了balances[msg.sender]溢出,强烈推荐所有数学运算都使用SafeMath进行,这个要点我们在第一期溢出漏洞中已经提到(敲黑板)。

  • 详细分析

1、假设普通用户向原合约(Reentrancy.sol)存入15 ether;

2、攻击者部署攻击合约(POC.sol),并调用setInstance()指向原合约部署地址;

3、攻击者调用攻击合约的depositEther()函数,预先向原合约预存1 ether,此时, 在原合约中,攻击合约的地址有1 ether余额;

4、攻击者调用攻击合约的withdrawFunds()函数,该函数再调用原合约的withdrawFunds()函数,并传参1 ether;

5、进入原合约,withdrawFunds()函数的第一行require(balances[msg.sender] >= _weiToWithdraw);,攻击合约地址下余额为1 ether,等于_weiToWithdraw,条件满足,进入下一行;

6、withdrawFunds()函数的第二行require(msg.sender.call.value(_weiToWithdraw)());,向msg.sender转入_weiToWithdraw(此时是1 ether),由于msg.sender是合约地址,solidity规定向合约地址接收到ether时如果未指定其他有效函数,那么默认会调用合约的fallback函数,执行流进入攻击合约,并调用攻击合约的fallback函数,并且,因为是通过call.value()()方式发送以太币,该方法会发送所有剩余gas;

7、进入攻击合约的fallback函数,if判断原合约余额,此时为16 ether,条件满足,再次"重入"原合约的withdrawFunds()函数;

8、再次进入原合约的withdrawFunds()函数,因为balances[msg.sender] -= _weiToWithdraw;并未执行,所以此时攻击合约地址仍有1 ether,第一个require条件满足,执行到第二个require;

9、此后步骤6-8将一直重复,直到原合约余额少于1 ether或者gas耗尽;

10、最后进入原合约,执行balances[msg.sender] -= _weiToWithdraw;,注意,此处会从balances[msg.sender]中减去所有提取的ether,导致balances[msg.sender]溢出,如果此处使用SafeMath,可以通过抛出异常的方式避免重入攻击。

最终的结果是攻击者只使用了1 ether,就从原合约中取出了所有的ether。

漏洞修复

1、 在可能的情况下,将ether发送给外部地址时使用solidity内置的transfer()函数4,transfer()转账时只发送2300 gas,不足以调用另一份合约(即重入发送合约),使用transfer()重写原合约的withdrawFunds()如下;

2、 确保状态变量改变发生在ether被发送(或者任何外部调用)之前,即Solidity官方推荐的检查-生效-交互模式(checks-effects-interactions);

3、 使用互斥锁:添加一个在代码执行过程中锁定合约的状态变量,防止重入调用

接述事件回顾,重入在DAO攻击中发挥了重要作用,最终导致了 Ethereum Classic(ETC)的分叉。有关The DAO原始漏洞的详细分析,请参阅Phil Daian的文章。

2. 交易顺序依赖攻击

  • 问题描述

与大多数区块链一样,以太坊节点汇集交易并将其形成块。一旦矿工解决了共识机制(目前Ethereum的 ETHASH PoW),这些交易就被认为是有效的。解决该区块的矿工也会选择来自该矿池的哪些交易将包含在该区块中,这通常是由gasPrice交易决定的。在这里有一个潜在的攻击媒介。攻击者可以观察事务池中是否存在可能包含问题解决方案的事务,修改或撤销攻击者的权限或更改合约中的对攻击者不利的状态。然后,攻击者可以从这个事务中获取数据,并创建一个更高级别的事务gasPrice 并在原始之前将其交易包含在一个区块中。

我们来看如下案例漏洞合约:

这个合约包含1000个ether,找到并提交正确答案的用户将得到这笔奖励。当一个用户找出答案Ethereum!。他调用solve函数,并把答案Ethereum!作为参数。不幸的是,攻击者可以观察交易池中任何人提交的答案,他们看到这个解决方案,检查它的有效性,然后提交一个远高于原始交易的gasPrice的新交易。解决该问题的矿工可能会因攻击者的gasPrice更高而先打包攻击者的交易。攻击者将获得1000ether,最初解决问题的用户将不会得到任何奖励(合约中没有剩余ether)。

  • 漏洞修复

有两类用户可以进行这种的提前交易攻击。用户(修改他们的交易的gasPrice)和矿工自己(他们可以按照他们认为合适的方式重新排序交易)。一个易受第一类(用户)攻击的合约比一个易受第二类(矿工)攻击的合约明显更糟糕,因为矿工只能在解决一个区块时执行攻击,这对于任何针对特定区块的单个矿工来说都是不可能的。在这里,我将列出一些与他们可能阻止的攻击类别相关的缓解措施。

可以采用的一种方法是在合约中创建限制条件,即gasPrice上限。这可以防止用户增加gasPrice并获得超出上限的优先事务排序。这种预防措施只能缓解第一类攻击者(任意用户)的攻击。在这种情况下,矿工仍然可以攻击合约,因为无论gasPrice如何,他们都可以根据需要排序交易。

更可靠的方法是尽可能使用提交---披露方案(commit-reveal)。这种方案规定用户使用隐藏信息(通常是散列)发送交易。在交易已包含在块中之后,用户发送一个交易解密已经发送的数据(披露阶段)。此方法可防止矿工和用户进行前瞻性交易,因为他们无法确定交易内容。然而,这种方法无法隐藏交易价值(在某些情况下,这是需要隐藏的有价值信息)。 ENS智能合约允许用户发送交易,其承诺数据包括他们愿意花费的以太数量。然后,用户可以发送任意值的交易。在披露阶段,用户退还了交易中发送的金额与他们愿意花费的金额之间的差额。

前事不忘,后事之师

DAO事件在当时区块链行业轰动一时,损失之重,令无数投资人捶胸顿足,我们总结下来,为了防止类似的情况发生,开发者应注意以下几点:
开发过程中注意查阅Solidity或者其他官方语言中是否已给出相关内置函数或者严谨的交互模式,如有应严格遵守,切不可异想天开;
勤于思考状态变量有可能发生的意外,对有潜在问题的状态变量应予以锁定;
综合运用gas限制以及披露方案,保障交易信息在合理的环节以合理的形式呈现。
区块链时代的安全问题都带有互联网发展早期的影子,安全知识的迁移以及防范意识的提升将会是斩除隐患的利刃。
欲知后事,且看下回:底层函数调用险象环生 外部功能慎用防患未然。

引用:

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,254评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,875评论 3 387
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,682评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,896评论 1 285
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,015评论 6 385
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,152评论 1 291
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,208评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,962评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,388评论 1 304
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,700评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,867评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,551评论 4 335
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,186评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,901评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,142评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,689评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,757评论 2 351

推荐阅读更多精彩内容