近期 Curve 的 Vyper 编译语言漏洞导致超过 7000 万美元被盗，此次的漏洞被称为「重入攻击」，本文将深入介绍重入攻击。本文源自 CyberPunkMetalHead 于 Medium 所着文章 《A Deep Dive Into How Curve Pool’s $70Million Reentrancy Exploit Was Possible》，由 星球日报Odaily 编译、整理。
（前情提要：导致Curve被骇的Vyper：第二智能合约语言，出了什么问题？ ）
（背景补充：Curve遭受重创，证明DeFi充满风险？ ）

本文目录

近期的 Curve池漏洞与我们在过去几年里看到的大多数加密货币骇客事件有所不同，因为与之前的许多漏洞不同，这一次并不直接与智慧合约本身的漏洞有关，而是与它所使用的语言的底层编译器有关。

在这里，我们谈论的是 Vyper：一个面向智慧合约的、具有Pythonic风格的编程语言，旨在与以太坊虚拟机（EVM）交互。我对此次漏洞的背后原因非常感兴趣，所以我决定深入研究。

随着这次漏洞的发展，每天的新闻头条都在报告新的数字。现在看来，情况终于得到了控制，但在此之前已经有超过 7000 万美元被盗。根据 LlamaRisk的事后评估，截止到今天，有几个 DeFi 项目的池子也被骇客攻破，包括PEGD 的 pETH/ETH: 1100 万美元；Metronome 的 msETH/ETH: 340 万美元；Alchemix 的 alETH/ETH: 2260万美元；和Curve DAO: 大约2470万美元。

这次漏洞被称为重入错误，它是在 Vyper 编程语言的某些版本上出现的，特别是 v0.2.15、v0.2.16 和 v0.3.0。因此，使用这些特定版本的 Vyper 的所有项目都可能成为攻击的目标。

什么是重入（reentrancy）？

为了理解这次漏洞为什么会发生，我们首先需要了解什么是重入以及它是如何工作的。

如果一个函数在执行过程中可以被中断，并且在其之前的调用完成执行之前可以安全地再次被调用「重新进入」，则称该函数为可重入的。可重入函数在硬体中断处理、递归等应用中都有使用。

为了使一个函数变得可重入，它需要满足以下条件：

这里有一个实际的例子：

i = 5
def non_reentrant_function():
return i5
def reentrant_function(number:int):
return number5

函数 non_reentrant_function：

函数 reentrant_function：

值得注意的是，许多智慧合约函数都不是可重入的，因为它们访问如钱包余额之类的全局信息。

什么是锁（Lock）？

锁本质上是一种线程同步机制，某个进程可以声称或「锁定」另一个进程。

最简单的锁类型被称为二进制信号量。这种锁为被锁定的数据提供独占访问。还有更复杂的锁类型，可以提供对读数据的共享访问。在编程中误用锁可能导致死锁或活锁，进程持续互相阻塞，状态不断改变但没有进展。

编程语言在后台使用锁来优雅地管理和共享多个子程式之间的状态更改。但是，某些语言，如 C# 和 Vyper 允许在程式码中直接使用锁。

@nonreentrant('lock')
def func():
assert not self.locked, "locked"
self.locked = True

Do stuff

Release the lock after finishing doing stuff

raw_call(msg.sender, b"", value=0)
self.locked = False

More code here

在上面的例子中，我们希望确保如果 msg.sender（合约呼叫者）是另一个合约，它不会在执行时调用程式码。如果在 raw_call() 下面还有更多的程式码，而没有锁，msg.sender 可能会在我们的函数执行完毕之前调用上面的所有程式码。

因此，在 Vyper 中，nonreentrant(‘lock’) 装饰器是一种控制对函数的访问的机制，以防止调用者在它们完成运行之前反复执行智慧合约函数。

在许多 DeFi骇客事件中，通常都是合约开发者没有预见到的智慧合约错误，一个聪明但恶意的利用者发现了某些函数或数据暴露的方式中的弱点。但这次的情况独特之处在于，Curve的智慧合约以及所有其他成为攻击受害者的池和项目在程式码本身中都没有已知的漏洞。合约是稳固的。

nonreentrant(‘lock’)是存在的。

由于 Vyper语言在处理重入锁的方式上出现了问题，导致了这个问题的发生。所以，合约创建者可能部署了看似合理的程式码，但由于编译器没有正确处理锁，使得攻击者能够利用这个有缺陷的锁进行利用，导致合约行为出现意料之外的结果。

让我们看看真正受到重入攻击的合约。注意 @nonreentrant(‘lock’) 修饰符吗？通常情况下，这应该可以防止重入，但实际上并未能防止。攻击者能够在函数返回结果之前反复调用 remove_liquidity()。

@nonreentrant('lock')
def remove_liquidity(
_burn_amount: uint256,
_min_amounts: uint256N_COINS,
_receiver: address = msg.sender
) -> uint256N_COINS:
"""
@notice Withdraw coins from the pool
@dev Withdrawal amounts are based on current deposit ratios
@param _burn_amount Quantity of LP tokens to burn in the withdrawal
@param _min_amounts Minimum amounts of underlying coins to receive
@param _receiver Address that receives the withdrawn coins
@return List of amounts of coins that were withdrawn
"""
total_supply: uint256 = self.totalSupply
amounts: uint256N_COINS = empty(uint256N_COINS)
for i in range(N_COINS):
old_balance: uint256 = self.balancesi
value: uint256 = old_balance * _burn_amount / total_supply
assert value >= _min_amountsi, "Withdrawal resulted in fewer coins than expected"
self.balancesi = old_balance - value
amountsi = value
if i == 0:
raw_call(_receiver, b"", value=value)
else:
response: Bytes32 = raw_call(
self.coins1,
concat(
method_id("transfer(address,uint256)"),
convert(_receiver, bytes32),
convert(value, bytes32),
),
max_outsize=32,
)
if len(response) > 0:
assert convert(response, bool)
total_supply -= _burn_amount
self.balanceOfmsg.sender -= _burn_amount
self.totalSupply = total_supply
log Transfer(msg.sender, ZERO_ADDRESS, _burn_amount)
log RemoveLiquidity(msg.sender, amounts, empty(uint256N_COINS), total_supply)
return amounts

这是如何被利用的？

到目前为止，我们知道重入攻击是一种反复调用智慧合约中的某个函数的方法。但这是如何导致资金被盗和在Curve 攻击中损失 7000 万美元的呢？

注意智慧合约末尾的 self.balanceOfmsg.sender -= _burn_amount 吗？这告诉智慧合约池中 msg.sender的流动性，减去燃烧费。接下来的程式码行为 message.sender 调用 transfer()。

因此，一个恶意合约可以在金额更新之前不断地调用提现，几乎让他们可以选择提取池中的所有流动性。

这样的攻击通常的流程是这样的：

这将重复，直到池中没有更多的流动性。

Vyper 语言中的这个问题已经被修复，在 0.3.0 版本之后不再存在。如果您是开发人员，或使用 Vyper 的 Web3 组织，请确保立即更新您的版本。

📍相关报导📍

Curve骇客还款6000ETH！嚣张讽：一群笨蛋快倒闭很可怜，不是怕被抓..

Curve清算危机暂歇，对DeFi及稳定币生态带来什么启示？

全解析 | 不可不知的 3种「Defi重入攻击」: 基本概念、背后细节、手法 — Amber资安负责人