原文链接：Systematic Approach to Maintaining EVM Compatibility and Security 

本文来自：BlockSec  编译：CoinTime Candice

EVM（以太坊虚拟机）兼容区块链旨在与以太坊区块链的智能合约功能、编程语言（Solidity）和工具生态系统兼容。在这个过程中，实现符合EVM的虚拟机是关键步骤之一。然而，在研究过程中，我们发现，在不同的实现中保持对EVM的兼容性并不容易。

为了解决这个问题，BlockSec开发了一个内部系统，可以系统地定位EVM实现中的错误和安全漏洞。这个系统被证明是有效的。它报告了Aurora Engine中的四个错误和Moonbeam中的四个错误的定位。所有这些都已报告并修复。请注意，该测试方法还用于定位去年Solana rbpf实施中的两个关键错误（CVE-2021-46102、CVE-2022-23066）。

1. 背景

如今，人们提出了许多不同的区块链，并在低gas费用、高吞吐量和高性能方面进行了优化。在这种情况下，新的虚拟机或开发语言被提出，这增加了原始实体开发者的转型门槛。在这种情况下，提出了许多与EVM兼容的解决方案，允许用户将他们在solidity中开发的DApp部署在这些新的链上。Aurora和Moonbeam是这些EVM兼容解决方案的代表。然而，这些EVM实现的稳健性、可靠性和精确性是未知的，值得我们关注。为此，我们使用差分模糊技术，并检查实现中是否存在任何缺陷。

2. 差分模糊测试

其基本思想是向这些EVM实现（例如Aurora、Moonbeam）和最先进的以太坊客户端（即geth）提供相同的输入，以检查它们是否具有相同的输出。具体来说，我们收集以太坊上的历史交易，并使用不同的策略改变合约代码和交易状态，以生成测试用例。我们的发现表明，Aurora Engine和Moonbeam在某些情况下不符合规范。幸运的是，所有报告的问题都得到了解决，现在我们将分享细节。

3. 发现错误

这些错误大多存在于预编译的合约中，其根本原因和影响是多方面的。例如，一些错误可能会影响nonce值的计算，而另一些可能影响gas的计算，并可能进一步导致DoS攻击。所有发现的错误都违反了EVM规范的指定执行逻辑，并可能在特定情况下导致意外行为。请看下面对所发现的错误的详细描述。

3.1 验证不当

加密逻辑是复杂的。在这种情况下，在EVM字节码中实现相应的逻辑可以产生相当大的gas用量。相反，在本机代码中开发的预编译合约可以提高性能。然而，由于验证不当，我们在预编译的合约中发现了几个错误。

Aurora Engine：ecPairing

这个错误是在预编译的合约ecPairing中发现的。

ecPairing的输入由两条椭圆曲线上的多个点组成。根据规范，点（0，0）位于两条曲线上，应为有效输入：

但是，如果输入中包含点（0,0），Aurora Engine（2.7.0版）将恢复。

Moonbeam: ecMul

这个错误出现在预先编译的合约ecMul中。与Aurora Engine不同，Moonbeam在输入有效时还原交易。根据规范，当输入的长度小于64时，预编译的合约ecMul应该用零填充输入。但是，Moonbeam会还原，而不是进行填充操作。

我们还发现，预编译的合约ecAdd和modexp有同样的问题。

Moonbeam: ecRecover

这个错误出现在预编译的合约ecRecover中，该合约用于恢复以太坊地址。

根据规范，输入[32..63]v表示U256标识符，它应该是27或28，否则ecRecover不应返回任何内容（但不应该还原整个交易）。

然而，Moonbeam在这里犯了两个错误：

Moonbeam: ecPairing

这个错误出现在预编译的合约ecPairing中。当输入无效时，Moonbeam不会恢复交易。根据规范，预编译的合约ecPairing的输入应该是192的倍数。否则，交易应该被退回。

然而，当上述要求不符合时，Moonbeam不会恢复交易。

3.2 Gas计算不正确

每个预编译合约都有一个算法来确定gas的使用量。不正确的gas计算可能会导致DoS攻击。

然而，我们在Aurora Engine和Moonbeam中都发现了两个错误，即gas计算不正确。

Aurora Engine: modexp

这个错误出现在预编译的合约modexp中。计算gas使用量的算法由EIP-2565定义。Gas使用量与迭代次数有关。

计算迭代次数的算法如下。

根据上述算法，迭代次数至少是1。然而，Aurora Engine直接返回iteration_count，而不是max（iteration_coount，1）。在这种情况下，返回的值（即iteration_count）可以是0，这意味着在特定情况下，Aurora将收取比预期更少的gas费用。

Moonbeam: modexp

这个错误也出现在预编译的合约modexp的函数calculate_iteration_count中。但它是在Moonbeam中发现的。

当exponent_length大于32时，iteration_count的计算方法如下。

请注意，它使用了exponent&（2**256-1），这需要exponent的最低32个字节，Moonbeam的实现也遵循了这种算法。

然而，根据规范，gas计算公式应使用最高32字节的exponent：

3.3 Nonce增量错误

一个外部拥有的账户（EOA）的nonce表示这个地址所签署的成功交易的数量。然而，我们注意到，可以通过在Aurora Engine上发送无效交易来增加nonce。

根据EIP-1559，在执行交易之前，EVM应该确保签署者有足够的余额来支付转移的本地代币（如ETH）和所需的gas。否则，该交易应被放弃，签署者的nonce也不应增加。

虽然Aurora Engine在这种情况下会放弃交易，但它仍然会增加签署者的nonce。

3.4 操作码实现不正确

这个错误是关于特定操作码（即PUSH）的实现。当PUSH操作码后面的字节不完整时，它们应该是右对齐的。例如，字节码0x64ffff可以被解码为：

由于操作数应该是右对齐的，值0xffff000000应该被推入堆栈。然而，Aurora Engine和Moonbeam中的EVM实现却推送了0xffff，这是不正确的。

4. 我们的服务

在BlockSec，我们了解在不同的区块链实施中保持EVM兼容性和安全性的重要性。这就是为什么我们开发了一种系统的错误检测方法，可以轻松定位EVM实现中的漏洞。

我们的内部系统已被证明在定位EVM实现中的漏洞和安全漏洞方面非常有效。它已经成功报告并修复了Aurora Engine中的四个错误和Moonbeam中的四个错误。此外，我们的测试方法用于定位去年Solana rbpf实施中的两个关键漏洞（CVE-2021-46102、CVE-2022-23066），突出了我们方法的有效性。

通过实施我们的系统性漏洞检测方法，我们的客户可以确信他们的EVM实施是安全和可靠的。我们致力于为EVM的兼容性和安全性提供一流的解决方案，帮助我们的客户与他们的用户和利益相关者建立信任。

关于BlockSec

BlockSec团队专注于区块链生态系统的安全，并与领先的DeFi项目合作以确保其产品的安全。该团队由来自学术界和工业界的顶尖安全研究人员和经验丰富的专家组成。他们在著名会议上发表了多篇区块链安全论文，报告了几起DeFi应用程序的零日攻击，并发布了高影响安全事件的详细分析报告。

*本文由CoinTime整理编译，转载请注明来源。