Aave 经历惊魂一刻，这个漏洞差点酿成一场危机

注：今日，DeFi 安全审计公司 Trail of Bits 披露了 Aave 借贷协议此前存在的一个严重漏洞，在发现到该问题后，Aave 迅速修复了该漏洞，从而避免了一场危机。

原文来自 Trail of Bits：

12 月 3 日，知名 DeFi 借贷协议 Aave 部署了 V2 版本，尽管我们并没有被雇佣来查看其代码，但在次日，我们还是对其进行了简单审查。很快，我们就发现了一个影响 Aave V1 和 V2 版本合约的漏洞，并报告了该问题。在将我们的分析发送给 Aave 的一小时内，他们的团队修复了该漏洞，以减轻潜在影响。如果该漏洞被利用，这一问题将破坏 Aave，并影响外部 DeFi 合约中的资金。

据悉，有 5 家不同的安全公司审查了 Aave 代码库，其中有一些使用了形式化验证。然而，这个漏洞并没有被这些公司注意到。这篇文章描述了这一问题，以及“该漏洞是如何逃过检测”等其它的一些经验教训。此外，我们也在开发一种新的 Slither 检测器，它可以识别这一漏洞，从而为以太坊社区提高安全性。

漏洞

Aave 使用了 delegatecall 代理模式，这一点我们在过去的文章中已经详细讨论过了。简单来看，每个组件被分成了两个合约：（1）包含实现的逻辑合约，（2）包含数据并使用 delegatecall 与逻辑合约进行交互的代理。在逻辑合约上执行代码时，用户与代理合约进行交互。这是 delegatecall 代理模式的简化表示：

在 Aave 中，LendingPool （LendingPool.sol）是使用 delegatecall 代理的可升级组件。

而我们发现的漏洞依赖于这些合约中的两个功能：

1. 可以直接调用逻辑合约的函数，包括初始化函数；

2. 借贷池具有其自己的 delegatecall 功能；

1

初始化可升级合约

这种可升级模式的一个限制是，代理不能依赖逻辑合约的构造函数（Constructor）进行初始化。因此，状态变量和初始设置必须在公共初始化函数中执行。

在 LendingPool 中，初始化函数设置提供者地址（_addressesProvider）：

initializer 调节器防止多次调用 initialize，它要求满足以下条件为 true：

以下：

1. 初始化允许在相同交易中多次调用调节器（因此有多个 initialize 函数）；

2. isConstructor （）是代理执行代码所需的；

3. revision > lastInitializedRevision 允许在合约升级时再次调用初始化函数；

虽然它通过代理，预期可正常工作，但是（3）也允许任何人直接在逻辑合约上调用 initialize 函数。一旦逻辑合约被部署：

1. revision 将为 0x2(LendingPool.sol#L56)；

2. lastInitializedRevision 将为 0x0；

而漏洞是：任何人都可以在 LendingPool 逻辑合约中设置_addressesProvider。

2

任意 delegatecall

LendingPool.liquidationCall 直接委托调用（delegatecall）由_addressProvider 返回的地址：

这允许任何人启动 LendingPool 逻辑合约，设置受控地址提供者，并执行任意代码，包括 selfdestruct。

利用漏洞的场景：任何人都可以破坏借贷池逻辑合约。下面是一个简化的视觉表示：

3

缺乏存在检查

就问题本身而言，已经是很严重了，因为任何人都可以破坏逻辑合约，并阻止代理执行借贷池代码。

然而，在代理合约中使用 OpenZeppelin 会加剧这一问题的严重性。

我们在 2018 年撰写的一篇博客文章中强调，没有代码的合约委托调用（delegatecall）能在不执行任何代码的情况下返回成功。尽管我们最初发出警告，但 OpenZeppelin 并未在其代理合约中修复回退函数：

如果代理委托调用（delegatecall）了一个已破坏的借贷池逻辑合约，则代理将返回成功，而不会执行任何代码。

由于 Aave 可以更新代理以指向另一个逻辑合约，因此这种漏洞利用不会持久。但在可利用此漏洞的时间范围内，任何调用该借贷池的第三方合约，都将表现为某些代码已被执行，但实际却并未执行。这将打破很多外部合约的基本逻辑。

4

受影响的合约

1. 所有 AToken （Aave 代币）：AToken.redeem 调用 pool.redeemUnderlying （AToken.sol#L255-L260)。由于调用什么也不做，用户将烧掉他们的 AToken，而不会收到他们的底层资产；

2. WETHGateway(WETHGateway.sol#L103-L111): 存款会存储在网关中，然后任何人都可以窃取存款资产；

3. 任何基于 Aave 信用委托 v2 （MyV2）的代码库 (MyV2CreditDelegation.sol)；

如果我们发现的问题被利用，则 Aave 之外的很多合约都会受到各种方式的影响。确定一份完整的名单是困难的，我们没有试图这样做。这一事件凸显了 DeFi 可组合性的潜在风险，以下是我们找到的一些受影响的合约：

1. DefiSaver v1 (AaveSaverProxy.sol)

2. DefiSaver v2 (AaveSaverProxyV2.sol)

3. PieDao – pie oven (InterestingRecipe.sol#L66)

5

修复及建议

幸运的是，在我们报告这个漏洞之前，还没有人利用它。Aave 对其两个版本的借贷池调用了 initialize 函数，从而保证了合约的安全：

1. LendingPool V1: 0x017788dded30fdd859d295b90d4e41a19393f423 修复时间 : 2020 年 12 月 4 日 07:34:26 PM +UTC

2. LendingPool V2: 0x987115c38fd9fd2aa2c6f1718451d167c13a3186 修复时间 : 2020 年 12 月 4 日 07:53:00 PM +UTC

长期而言，合约部署者应：

1. 在所有逻辑合约中添加一个构造函数（constructor ）以使 initialize 函数无效；

2. 检查 delegatecall 代理 fallback 函数中是否存在合约；

3. 仔细检查 delegatecall 陷阱，并使用 slither-check-upgradeability；

6

形式化验证合约并不是防弹的

Aave 的代码库经过了形式化验证，区块链领域的一个趋势是，人们会认为安全特性是圣杯。用户可能会尝试根据这些特性的存在与否，对各种合约的安全性进行排序。我们认为这是危险的，它会导致错误的安全感。

Aave 形式化验证报告列出了 LendingPool 视图函数（例如，它们没有副作用）以及池操作（例如，操作成功后返回 true 且不还原）的属性。例如，已验证的属性之一是：

然而，如果逻辑合约遭到破坏，则该属性可能会被破坏。那如何才能对此进行验证？虽然我们无法访问定理证明或所使用的设置，但很可能证明 proof 没有考虑可升级性，或者 prover 不支持复杂的合约交互。

这在代码验证中是很常见的。你可以通过对整体行为的假设来证明目标组件中的行为，但是在多合约设置中证明属性是具有挑战性和耗时的，因此必须进行权衡。

形式化验证技术很棒，但是用户必须意识到它们覆盖范围很小，并且可能会错过攻击媒介。另一方面，自动化工具和人工审查可帮助开发人员以较少的资源来提升代码库的安全性。了解每种解决方案的优点和局限性，对开发人员和用户而言都至关重要。当前的问题就是一个很好的例子，Slither 可以在几秒钟内发现这个问题，受过训练的专家可能会很快指出它，而要用安全特性来检测，则需要付出很大的精力。

总结

Aave 做出了积极反应，并在发现问题后迅速修复了该漏洞。危机避免了，但最近遭受黑客攻击的其他受害者却没有那么幸运。在部署代码并将其暴露于对抗性环境之前，我们建议开发者：

1. 查看这里的检查表和训练；

2. 将 Slither 添加到你的持续集成管道中并调查其所有报告；

3. 给安全公司适当的时间来审查你的系统；

4. 请注意可升级性，至少请审查合约升级反模式，合约迁移的工作方式，以及使用 OpenZeppelin 的可升级性；

我们希望通过分享此信息以及与此问题相关的 Slither 检测器来防止类似的错误。

欢迎加入社群，与我们讨论如何参与更多 DeFi 项目、探索 DeFi 规则原理~

加入方式：扫码关注，后台点击【加入社群】

DeFi 之道公众号后台

回复“财富”获取 DeFi 热门项目白皮书合集 !

回复“研究”获取 DeFi 研究报告合集！

回复“论文”获取 DeFi 相关论文合集！

干货持续更新中，敬请关注……