以太坊漏洞可导致“重入攻击”风险？

  • Z时代
  • 2024-01-10
  • 分类：IT

作者:BCSEC

公众号:DVPNET

前言

1月16日凌晨,以太坊准备进行君士坦丁堡硬分叉的前一日被披露出来了一则漏洞，该漏洞由新启动的EIP 1283引起，漏洞危害准确的说应该是一种可能会让一些合约存在重入漏洞的隐患，而不是一定会使合约产生重入漏洞。该漏洞在被发现之后以太坊基金会立马宣布了停止硬分叉，并商议择日再启动以太坊君士坦丁堡硬分叉。

一、导致以太坊延迟硬分叉的EIP 1283到底是什么？

EIP的全称是Ethereum Improvement Proposals（以太坊改进提案），任何人都可以上去提一些对以太坊的改进提案，不过必须得严谨、正式，以太坊君士坦丁堡这次漏洞就是由一个EIP引起的，这个EIP的编号是1283。EIP 1283使以太坊虚拟机使执行智能合约的引擎更高效，并降低在以太坊上运行智能合约的成本。

该提案是针对SSTORE操作码的，该操作码主要用于合约持久化存储数据，EIP1283为SSTORE操作码设计了更加合理的gas收费方式。

详情地址如下：

https://eips.ethereum.org/EIPS/eip-1283

为什么需要EIP 1283？

EIP-1283提案由Wei Tang(@sorpass)于2018年8月1日创建，作为EIP-1087和EIP-1153的替代方案。EIP-1087由Nick Johnson创建，主要是改变EVM SSTORE运行gas费用收取方式，减少过多的gas费用成本;EIP-1153由Alexey Akhunov创建，相比EIP-1087更加便宜，gas费用计算规则更加简单。EIP-1283提出了在SSTORE上进行gas计量的方案，为数据存储的变化引进更加合理公平的定价方案。

其中定义了三个概念：

  • 存储槽的原始值（original）：在当前事务发生回滚（revert）后会存在的值叫原始值。

  • 存储槽的当前值（current）：在使用SSTORE操作码之前存在的值叫当前值。

  • 存储槽的新值（new）：在使用SSTORE操作码之后存在的值叫新值。

然后以这三个概念为基础，设计了如下处理逻辑：

如果当前值等于新值（这是无操作），则扣除200 gas。
如果当前值不等于新值
    如果原始值等于当前值（此存储槽未被当前执行上下文更改）
        如果原始值为 0，则扣除20000 gas。
        否则，扣除5000 gas。如果新值为 0，则在退款计数器中增加15000 gas（退款计数器中记录的gas会退还给用户）。
    如果原始值不等于当前值（代表此存储槽”脏”了），则扣除200 gas。
        如果原始值不为0
            如果当前值为 0（也表示新值不为0），请从退款计数器中减少15000 gas。
            如果新值为 0（也表示当前值不为0），请向退款计数器中增加15000 gas。
        如果原始值等于新值（此存储槽已重置）
            如果原始值为 0，则将退款计数器中增加19800 gas。
            否则，则在退款计数器中增加4800 gas。

根据如上的逻辑可以发现，当使用SSTORE操作码的时候如果不改变任何值的时候，只消耗 200 gas。如果改变了值最终又重置为0的话也只消耗20000 + 200 - 19800 = 400 gas。

而在之前EIP 1087的逻辑中如果使用SSTORE操作码改变了值最终又重置为0的话需要消耗20000 + 5000 - 10000 = 15000 gas。

显然EIP 1283的处理逻辑比EIP 1087更加合理，也更加便宜，但是问题就在这里。

二、EIP 1283漏洞分析

重入漏洞是指在同一笔交易中因两个合约互相调用而导致合约进行重复转账的一种现象，其产生的根源是没有使转账作为事务的最后一个步骤。

比如说，如果在转账之后再进行状态变更的话就很容易重入漏洞，最经典的一起事件就是The DAO事件，所以最安全的做法是一笔事务中只有一笔转账，且在转账之前做好所有状态变更，转账作为最后一个操作进行，如果以这种标准来实现的话，是不会受EIP 1283影响的，所以这就是为什么说EIP 1283 只是可能使某些合约产生重入漏洞隐患。

那么，什么样的合约容易产生这种隐患？请看以下Demo。

这是一个模拟资金共享服务的合约，资金余额由deposits变量存储，然后由splits变量存储分配比例。

比如有一笔资金需要a和b共同分配

  • 首先调用init函数存储双方的钱包地址

  • 调用deposit函数向通道充钱

  • 调用updateSplit函数来改变通道的分配率

  • 执行splitFunds函数分配资金

如果1号通道的分配率是99，那么执行splitFunds函数的时候给a分配通道中99%的资金，给b分配1%的资金。

该合约大概业务就是这样，在EIP 1283生效之前，该合约是没有重入漏洞的，EIP 1283生效才会存在重入漏洞。

前面提到过了，在EIP 1283中如果将一个值更改后又重置为0 ，那么只消耗400 gas。

再看看是怎么实现按比例分配的：

所以我们可以将a账户设置为我们的恶意合约，在合约的fallback函数中调用updateSplit函数来改变通道的分配率，使两个地址都能分到超过通道余额总量的币.

比如说我先给a账户分配100%的通道余额，再在a账户合约fallback函数中改变通道分配率，又给b账户分配100%的余额，这样就成功套出了双倍的钱，而且攻击者可以一直套，直到掏空为止。

攻击者Demo：

Ps：为了节约gas，fallback函数中使用内联汇编来模拟调用updateSplit函数。

调用attack函数即可触发重入漏洞。

为什么说要EIP 1283生效才会产生漏洞呢，因为该合约使用transfer进行转账，transfer转账最多消耗2300 gas，在EIP 1283生效之前对变量进行更改再重置至少需要15000 gas，而生效后只需要400 gas，2300 gas上限已经足够做一些事情了。

三、漏洞复现

关于该漏洞的复现，ChainSecurity已经在Github上公开了。

先clone下来

git clone https://github.com/ChainSecurity/constantinople-reentrancy.git

然后README里面会告诉你怎么复现，不过在此之前先得把环境装好，需要环境：

\1. nodejs(stable)
\2. npm
    a. truffle：npm install -g truffle
    b. ganache-cli@beta：npm i -g ganache-cli@beta

不同的系统有不同的环境搭建方式，这里不再赘述，有了以上环境就可以进行复现了，运行以下命令：

ganache-cli --hardfork=constantinople
truffle test

运行结果：

在进行攻击之后成功增加攻击账户内的余额，复现完毕。

四、修复方案

修复方案预计应该会在以太坊君士坦丁堡中删除与EIP 1283有关的更新，目前以太坊开发者还在协商解决，不过笔者认为合约安全最终还是要合约来解决，不能依赖于公链本身，就像前面说的，只要合约采用的是最安全的写法便可以避免这次君士坦丁堡分叉带来的问题。

而且目前还没有检测出来有合约正好会触发这个重入漏洞，但不排除这种可能性。

参考链接

以上是 以太坊漏洞可导致“重入攻击”风险？ 的全部内容， 来源链接： utcz.com/p/199214.html

回到顶部