编译器漏洞无解？Runtime Protection实现DeFi链上风控保护

原文作者：Artela 中文博客

TL; DR

重入攻击仍然是一个挑战，现有的防御手段主要集中在协议源代码层面，仅在合约进入 runtime 状态前生效

「运行时保护」是 DeFi 安全的重要补充，它以「保护执行结果」为目的，确保协议的执行与其预期设计一致

EVM 的设计不支持「运行时保护」，因为智能合约无法访问 runtime 状态全部上下文信息

Artela 探索一种 EVM+Extension 的执行层范式，增强执行层以消除重入攻击

Artela 通过 Aspect Programming 实现链上「运行时保护」扩展

我们逐步展示了如何通过 Aspect 防范对 Curve 合约的重入攻击

为什么尽管存在风险控制措施，重入攻击仍然是一个挑战

尽管重入攻击是一个众所周知的问题，并且出现了许多风险控制措施，但在过去的两年中，涉及此类攻击的安全事件仍在不断发生：

Curve Finance 攻击（2023 年 7 月）—6000 万美元，Curve 因其合约编程语言 Vyper 编译缺陷遭受重入攻击。

Origin Protocol 攻击（2022 年 11 月）—700 万美元，稳定币项目 Origin Dollar（OUSD）遭受了重入攻击。

Siren Protocol 攻击（2021 年 9 月）—350 万美元，AMM 池遭受重入攻击。

Cream Finance 攻击（2021 年 8 月）—1880 万美元，攻击者利用重入漏洞进行二次借贷。

目前，防范重入攻击的重点集中在智能合约的源代码层面，措施包括集成 OpenZeppelin 的 ReentrancyGuard，以及对合约逻辑代码进行安全审计，以避免预定义的安全隐患。

这种方法被称为「白盒」解决方案，旨在在源代码层面规避漏洞，以最小化逻辑错误。然而，其主要挑战在于无法防御未知隐患。

将合约从源代码「转化」为实际 runtime 是个具有挑战性的过程。每一步可能为开发人员带来无法预料的问题，而合约源代码本身可能无法全面涵盖所有潜在情况。在 Curve 的案例中，由于编译器问题，即使协议源代码是正确的，最终运行结果与协议的预期设计之间仍可能存在差异。

仅仅依靠协议在源代码和编译层面的安全性是不足够的。即使源代码看起来毫无瑕疵，由于编译器问题，漏洞仍可能意外出现。

我们需要运行时保护

与现有的风险控制措施集中在协议源代码层面并在运行之前生效不同，运行时保护涉及协议开发人员编写运行时保护规则和操作，以处理运行时的未预料情况。 这有助于对运行时执行结果进行实时评估及应对。

运行时保护在增强 DeFi 安全性方面至关重要，是现有安全措施的重要补充。通过以「黑盒」方式保护协议，它通过确保最终运行结果与协议预期设计相一致来增强安全性，而无需直接干涉合约代码执行。

实施运行时保护的挑战

不幸的是，EVM 设计不支持在链上实现运行时保护，因为智能合约无法访问完整的运行时上下文。

如何克服这一挑战？我们认为以下先决条件是必要的：

一个专门的模块，可以访问跨智能合约的所有信息，包括整个交易上下文。

从智能合约获得必要的授权，使模块有权根据需要回撤 (revert) 交易。

确保模块的功能在智能合约执行后和状态提交之前生效。

EVM 在解决上述挑战中目前面临限制，难以容纳更多创新。在模块化区块链的范式下，执行层需要探索 go beyond EVM 的突破。

Artela 的思路是 EVM + native extension，通过构建 EVM 的 WASM 原生扩展层以实现 go beyond EVM。

Aspect Programming 介绍

我们推出了 Aspect Programming，这是支持 Artela 区块链的一种编程框架，支持在区块链上进行原生扩展。

Aspect 是可编程的原生扩展模块，用于在运行时动态集成自定义功能到区块链中，作为智能合约的模块化补充，增强链上功能性。

Aspect 的特性是能够访问区块链基础层的系统级 API，并在交易生命周期的各个切点（Join Point）添加扩展逻辑。智能合约可以绑定指定的 Aspect 以触发扩展功能。当交易调用智能合约时，该交易也会经由与该合约关联的 Aspect 处理。

Aspect Programming 如何实现运行时保护

Aspect 可以记录每个函数调用的执行状态，并防止在回调函数执行期间发生重入。当在回调函数执行期间发生重入调用时，Aspect 会检测到并立即回撤该交易，防止攻击者利用重入漏洞。通过这种方法，Aspect 有效地消除了重入攻击，确保智能合约的安全性和稳定性。

Aspect 实现运行时保护的关键属性：

可在智能合约执行后和状态提交前触发：Aspect 模块可设置为在智能合约执行后但在状态提交前激活。

完整的交易上下文访问：Aspect 可以访问完整的交易上下文，包括整个交易信息（方法，参数等）、调用栈（执行过程中所有内部合约调用）、状态上下文变更以及所有交易触发的事件。

系统调用能力：Aspect 可以进行系统调用，并在必要时发起交易回撤。

与智能合约的绑定和授权：智能合约可以绑定到 Aspect，并授予 Aspect 参与交易处理的权限。

实施 Aspect 进行重入保护

本章我们探讨如何在链上实现 Aspect 的运行时保护。

可以在「preContractCall」和「postContractCall」的切点（Join Point）中部署一个实际的「合约保护意图」Aspect，以防止重入攻击。

preContractCall: 在跨合约调用执行之前触发

postContractCall: 在跨合约调用执行后触发

为进行重入保护，我们的目标是在调用结束之前阻止合约重入。通过 Aspect，我们可以通过在交易生命周期的切点处添加特定逻辑来实现这一目标。

在「preContractCall」切点中，Aspect 监控合约调用堆栈。如果在调用堆栈中有任何重复调用（这意味着我们锁定的调用中出现了意外重入），Aspect 将会回撤该调用。

部署 Curve 合约并防范重入攻击

我们编写了 Curve 模拟合约并复刻重入攻击，以更易理解的方式重现了这个过程。合约代码如下：

可以看到，上述合约的 add_liquidity 和 remove_liquidity 都由同一个重入锁 lock 进行了保护，这意味着如果重入保护正常工作，无法通过改锁重入被保护函数（例如，在 remove_liquidity 中调用 add_liquidity）。

使用 vyper 编译器 0.2.15、0.2.16 或 0.3.0（这些版本存在已知的重入保护问题）编译上述合约。

然后，我们部署上述受害者合约，并使用以下合约对其进行攻击：

模拟实际攻击，此合约的 attack 方法尝试通过其 fallback 函数从 remove_liquidity 方法重入 add_liquidity。如果实际发生了重入，可在 receipt 中观察到在 RemoveLiquidity 事件之前记录了一个 AddLiquidity 事件。

现在让我们使用 Aspect 来保护受攻击的合约。在执行以下操作之前，请先完成以下步骤：

1、部署 Aspect

2、将受害合约与 Aspect 绑定

如果对 Aspect 操作不熟悉，可以首先查看我们的先行了解。

完成上述操作后，现在让我们尝试再次调用 attack 方法，以检查操作是否会成功进行。

从动图（文末原文链接可查看）中我们可以看到，重入交易已经被 revert，这意味着我们的 Aspect 正在成功保护受害合约免受重入攻击。

结论

最近对 Curve 的攻击再次说明了没有 100% 完全安全的协议。仅仅将重心放在协议的源代码和编译级别的安全性上是不足够的。即使源代码看起来毫无瑕疵，由于编译器问题，漏洞仍然可能意外出现。

为了增强 DeFi 的安全性，运行时保护变得至关重要。通过以「黑盒」方式保护协议，确保协议的执行与其预期设计一致，可以有效地防止运行时的重入攻击。

我们复刻了 Curve 合约并完全模拟了其近期的重入攻击，并以更易理解的方式再现了整个过程。利用 Aspect 编程作为一种新方法，实现链上运行时保护，我们逐步展示了如何用 Aspect 保护受害合约。我们的目标是帮助根除 Curve 等 DeFi 协议可能遭受的重入攻击，从而增强整个 DeFi 领域的安全性。

通过 Aspect Programming，开发人员不仅可以在安全领域实现链上运行时保护，还能实现诸如意图、JIT 和链上自动化等前所未有的创新用例。除此之外，这个以 Cosmos SDK 为基础的通用框架将不仅支持 Artela 区块链，更能支持其他区块链构建基于自己执行层的 native extension。