2023-08-07 08:59 | 出处： odaily
原文《A Deep Dive Into How Curve Pool’s ￥ 70 Million Reentrancy Exploit Was Possible》，作者：Ann，由Odaily星球日报 jk 编译。
近期的 Curve 池漏洞与我们在过去几年里看到的大多数加密货币黑客事件有所不同，因为与之前的许多漏洞不同，这一次并不直接与智能合约本身的漏洞有关，而是与它所使用的语言的底层编译器有关。
在这里，我们谈论的是 Vyper：一个面向智能合约的、具有 Pythonic 风格的编程语言，旨在与以太坊虚拟机（EVM）交互。我对此次漏洞的背后原因非常感兴趣，所以我决定深入研究。
随着这次漏洞的发展，每天的新闻头条都在报告新的数字。现在看来，情况终于得到了控制，但在此之前已经有超过 7000 万美元被盗。根据 LlamaRisk 的事后评估，截止到今天，有几个 DeFi 项目的池子也被黑客攻破，包括 PEGD 的 pETH/ETH: 1100 万美元；Metronome 的 msETH/ETH: 340 万美元；Alchemix 的 alETH/ETH: 2260 万美元；和 Curve DAO: 大约 2470 万美元。
这次漏洞被称为重入错误，它是在 Vyper 编程语言的某些版本上出现的，特别是 v 0.2.15、v 0.2.16 和 v 0.3.0 。因此，使用这些特定版本的 Vyper 的所有项目都可能成为攻击的目标。
它不能使用全局和静态数据。这只是一种约定，没有硬性的限制，但如果使用全局数据的函数被中断和重新启动，它可能会丢失信息。
它不应修改自己的代码。无论函数何时被中断，都应该能够以相同的方式执行。这可以管理，但通常不建议这样做。
它不应该调用其他非重入函数。 重入不应与线程安全混淆，尽管它们紧密相关。一个函数可以是线程安全的，但仍然不是可重入的。为了避免混淆，重入只涉及到一个线程的执行。这是在没有多任务操作系统存在的时代的一个概念。
这里有一个实际的例子：
i ＝ 5
def non_reentrant_function():
return i＊＊ 5
def reentrant_function(number:int):
return number＊＊ 5
函数 non_reentrant_function：
这个函数没有参数。
它直接返回全局变量 i 的五次方。
所以当你调用这个函数时，它总是返回 5＊＊ 5 ，即 3125 。
函数 reentrant_function：
这个函数有一个参数 number，是整型。
它返回参数 number 的五次方。
这意味着你可以给这个函数传入任何整数，并得到这个数的五次方作为返回值。例如，如果你传入 2 ，它会返回 2 的 5 次方 ，即 32 。
值得注意的是，许多智能合约函数都不是可重入的，因为它们访问如钱包余额之类的全局信息。
在上面的例子中，我们希望确保如果 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: uint 256,
_min_amounts: uint 256 [N_COINS],
_receiver: address ＝ msg.sender
) -＆gt； uint 256 [N_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: uint 256 ＝ self.totalSupply
amounts: uint 256 [N_COINS] ＝ empty(uint 256 [N_COINS])
for i in range(N_COINS):
old_balance: uint 256 ＝ self.balances[i]
value: uint 256 ＝ old_balance ＊ _burn_amount / total_supply
assert value ＆gt；＝ _min_amounts[i], "Withdrawal resulted in fewer coins than expected"
self.balances[i] ＝ old_balance - value
amounts[i] ＝ value
if i ＝＝ 0:
raw_call(_receiver, b"", value＝value)
else:
response: Bytes[ 32 ] ＝ raw_call(
self.coins[ 1 ],
concat(
method_id("transfer(address, uint 256)"),
convert(_receiver, bytes 32),
convert(value, bytes 32),
),
max_outsize＝ 32,
)
if len(response) ＆gt； 0:
assert convert(response, bool)
total_supply -＝ _burn_amount
self.balanceOf[msg.sender] -＝ _burn_amount
self.totalSupply ＝ total_supply
log Transfer(msg.sender, ZERO_ADDRESS, _burn_amount)
log RemoveLiquidity(msg.sender, amounts, empty(uint 256 [N_COINS]), total_supply)
return amounts
到目前为止，我们知道重入攻击是一种反复调用智能合约中的某个函数的方法。但这是如何导致资金被盗和在 Curve 攻击中损失 7000 万美元的呢？
注意智能合约末尾的 self.balanceOf[msg.sender] -＝ _burn_amount 吗？这告诉智能合约池中 msg.sender 的流动性，减去燃烧费。接下来的代码行为 message.sender 调用 transfer()。
因此，一个恶意合约可以在金额更新之前不断地调用提现，几乎让他们可以选择提取池中的所有流动性。
这样的攻击通常的流程是这样的：
易受攻击的合约有 10 个 eth。
攻击者调用存款并存入 1 个 eth。
攻击者调用提现 1 个 eth，此时提现函数执行一些检查：
攻击者的账户中是否有 1 个 eth？是的。
将 1 个 eth 转移到恶意合约。注意：合约的余额尚未更改，因为该函数仍在执行。
攻击者再次调用提现 1 个 eth。（重新入场）
攻击者的账户中是否有 1 个 eth？是的。
这将重复，直到池中没有更多的流动性。
Vyper 语言中的这个问题已经被修复，在 0.3.0 版本之后不再存在。如果您是开发人员，或使用 Vyper 的Web3组织，请确保立即更新您的版本。