Solady 审计以增强整个生态系统的链上安全

简而言之：Base 资助了 Solady 库的全面第三方安全审计，以主动识别和解决多个安全问题。因此，Solady v0.1.1 已发布，强烈建议开发者升级到这个更安全的版本。

安全性是在链上构建的基础。 在 Base，我们致力于让更广泛的 Ethereum 生态系统对每个人都更安全。我们自身智能合约的强大安全标准是不够的——整个生态系统都需要是安全的。提高链上安全态势最有效的方法之一是帮助确保广泛使用的智能合约库尽可能地健壮。这些库是数千个项目（包括 Coinbase 运营的一些项目）的基础，任何漏洞都可能产生广泛的影响。

这就是为什么 Base 资助了对 Solady 的全面第三方安全审计，Solady 是一个广泛使用的 Solidity 智能合约库，以其 gas 优化的实用程序和在智能合约开发者社区中的广泛采用而闻名。

今天，我们很自豪地宣布，Solady 的审计已经完成，多个安全问题已得到主动解决，并且一个新的、更安全的版本 —— Solady v0.1.1 —— 现已上线。开发者应立即升级到此版本，以确保他们使用的是迄今为止 Solady 实用程序的最安全、最强大实现。

为什么选择 Solady？

Solady 迅速成为最受欢迎的 Solidity 库之一，提供 ERC20、ERC721、ERC1155 代币的优化实现，以及高效的字符串操作、低 gas 代币转账和数学函数等实用程序。它被广泛应用于 DeFi 生态系统、NFT 平台和其他优先考虑效率和安全性的区块链应用中。

虽然 Base 本身仅在生产中使用了一些选定的 Solady 合约，但我们认识到其安全性具有深远的影响。成千上万的开发者和项目（包括那些处理大量用户资金的项目）依赖于 Solady 的正确性和健壮性。鉴于它被迅速采用并深度集成到各种协议中，很明显，全面的安全审计将是对整个生态系统有价值的公共产品。

通过主动审计 Solady，Base 旨在实现以下目标：

• 在漏洞被利用之前识别并修复它们。

• 提高对 Solady 代码库安全性的信任。

• 建立安全高效的 Solidity 库的最佳实践。

审计

Solady 审计由 Spearbit 进行，Spearbit 是一家在智能合约审计方面享有盛誉的安全公司。审计历时五周，期间发现了 58 个问题并得到解决。这些问题范围从 minor gas 优化到关键漏洞，如果这些漏洞未得到解决，可能会产生重大的安全影响。一些关键发现包括：

• 取消 bytes32(0) 允许 Timelock 接管： 此问题可能使攻击者能够通过利用取消机制来接管 Timelock 合约。这将允许重新初始化合约，从而导致对时间锁定功能的未授权控制。

• 关于 calldata 数组结构的不合理假设： 关于 calldata 数组结构的不正确假设可能导致意外行为和潜在的漏洞。这在内联汇编中访问 calldata 数组时尤其成问题，因为它可能导致数组被截断或扩展为其他字节，从而导致下游代码接收到不正确且可能被篡改的数据。

• 更改 initializableSlot() 可能会导致 disableInitializers() 实际上启用初始化器： 此问题可能导致意外启用初始化器，从而危及合约的初始化逻辑。

总而言之，审计发现了 2 个严重、3 个高、7 个中和 8 个低严重程度的漏洞，以及 23 个信息性发现和 11 个 gas 优化建议。由于这项工作，我们已成功识别并采取措施解决所有 58 个漏洞。完整审计报告 提供了每个问题、严重程度以及为解决这些问题而采取的步骤的详细分解。

深入研究一个严重漏洞

除了上述高严重性发现之外，我们还将深入研究一个涉及使用 Spearbit 审计发现的 Solady 的 ERC-6492 实现 的严重漏洞。ERC-6492 旨在构建在 ERC-1271 之上，ERC-1271 是一种智能合约验证签名的方式。与具有私钥的传统 EOA 不同，智能合约无法签署交易。相反，智能合约钱包公开一个 isValidSignature 函数来执行签名验证，其中拥有智能合约钱包的有效签名者（即 EOA 或 passkey）能够签署交易。

ERC-6492 更进一步，允许用户将 ERC-1271 签名与工厂 calldata 以及工厂地址一起包装，该工厂地址将用于部署新的智能合约（智能合约钱包通过 工厂模式 部署，因此需要工厂地址）。这样做的好处是，它允许任何链下用户代表尚未部署的合约验证签名（通过模拟）。

ERC-6492 签名验证可能会发生 3 种情况：

1. 如果合约已部署，则生成正常的 ERC-1271 签名

2. 如果合约尚未部署，则按以下方式包装签名：concat(abi.encode((create2Factory, factoryCalldata, originalERC1271Signature), (address, bytes, bytes)), magicBytes)

3. 如果合约已部署但尚未准备好使用 ERC-1271 进行验证，则按以下方式包装签名：concat(abi.encode((prepareTo, prepareData, originalERC1271Signature), (address, bytes, bytes)), magicBytes); prepareTo 和 prepareData 必须包含使合约准备好使用 ERC-1271 进行验证的必要交易（例如，调用 migrate 或 update）

这里的关键是，在 Solady 的实现中，如果我们看到 magic bytes (0x6492…) 附加到签名，那么将跳过步骤 1，并且执行将继续执行步骤 2 和 3。不同的执行场景可以在以下代码中看到：

具体来说，此函数实现中的一个可被利用的漏洞是签名最初失败，导致合约在其第二次尝试验证签名时对其任意地址执行任意调用（如上图绿色框所示）。从 Spearbit 的审计中，我们可以展示以下 POC 和使用 Solady 的 SignatureChecker 库的易受攻击的 vault 示例：

我们的利用场景如下：

1. 编码一个恶意签名 payload：

   • prepareTo = 我们想要窃取的 ERC20 代币

   • prepareData = abi.encode(“transfer(address,uint256)”)

   • 插入 magic bytes

2. 在 vault 合约上调用易受攻击的 transferWithSig 函数，使用我们的恶意 DrainerHelper 合约作为签名者

3. 让 vault 将所有 ERC20 代币发送到 DrainerHelper 利用合约并获利

实际上，这就是利用合约的样子，其中包含恶意 payload 和函数调用。以下 POC 显示了一个测试用例，该测试用例在 vault 合约上调用 transferWithSig 函数，使用我们的 DrainerHelper 合约作为签名者：

感谢 Spearbit 研究员 Philogy 提供的概念证明

现在让我们逐步了解当在 vault 的 transferWithSig 函数内部调用 Solady 的 isValidERC6492SingatureNowAllowSideEffects 函数时，它的每个执行步骤是如何执行的：

在 POC 的结尾，我们可以看到 vault 已成功耗尽，并且攻击者合约现在拥有 vault 的所有 ERC20 代币。此漏洞的修复在于让库函数本身不进行直接的任意调用，而是让一个 中间合约 执行直接调用。这分离了特权调用者（在本例中是我们的 vault 合约）和签名的验证调用。由于推荐的调用流程现在是 vault 合约调用另一个没有任何特权的中间合约，然后进行任意调用来验证签名，因此这消除了直接从 vault 转出资金的能力。

结果：Solady v0.1.1 发布

作为此审计的直接结果，Solady 的维护者发布了 Solady v0.1.1，其中包括所有已识别安全漏洞的补丁。此版本代表迄今为止 Solady 最安全的版本，我们强烈建议所有开发者开始使用 v0.1.1。

为了完全透明，完整审计报告 是公开的，因此开发者可以查看调查结果、了解改进并评估他们自己的实现方式的安全性。

通过资助此 Solady 审计，我们希望提高 Solidity 智能合约开发的安全性态势，并鼓励开发者将安全性作为开发的基本组成部分来优先考虑。

展望未来：Base 在链上安全中的作用

在 Base，安全性是我们的首要任务，我们认为安全性应该是一项共同的责任。虽然我们在内部保持严格的安全标准，但我们也认识到安全性对更广泛的生态系统的重要性。这就是为什么我们投资于安全研究、资助对关键开源基础设施的审计，并为有益于整个 Base 和链上开发者生态系统的最佳实践做出贡献。

开源智能合约库的安全性对于链上生态系统的健康和可持续性至关重要。由于数千个项目依赖于 Solady，Base 主动资助了 Spearbit 的审计，将其作为一项公益事业，确保开发者和用户都可以从更安全的基础中受益。

如果你有兴趣从事高级链上安全挑战，请在此处浏览我们的空缺职位 here。你还可以关注我们的 X（Base 团队 和 基于社区的构建者）、Farcaster 和 Discord，以随时了解 Base 的最新信息。

• 原文链接： blog.base.dev/base-spons...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～