Safe 是一个多重签名 智能合约 钱包，专为集体管理数字资产而设计。 该钱包需要预定义的所有者签名阈值才能执行任何交易。 为了增强功能，Safe 通过模块和回退处理程序支持扩展。
Safe 委托 Ackee Blockchain Security 对 Safe Smart Account 进行安全审查，总共捐赠了 20 个 工程日，时间为 2025 年 4 月 14 日至 5 月 12 日。 其中 6 个 工程日 专门用于使用 Wake 测试框架进行手动引导的差异模糊测试。
第二次修复审查于 2025 年 5 月 20 日至 5 月 27 日进行。
方法论
我们首先对代码库进行手动审查，同时使用 Wake 测试框架进行手动引导的模糊测试。 对于静态分析，我们使用了 Wake 漏洞和代码质量检测器。
在审查期间，我们专注于确保：
- Safe 的基本概念（例如所有者管理和签名检查）保持正确实施；
- 重构的标记为内存安全的程序集块确实是内存安全的；
- 不可能发生重入和抢跑攻击；
- ERC-165、ERC-1271 和 EIP-712 等标准得到正确实施；
- 整数溢出和下溢不会导致安全漏洞；
- 该合约与 ERC-4337 智能账户兼容；
- 通过
CompatibilityFallbackHandler 合约完全实现向后兼容； 并且
- 不存在诸如数据验证之类的常见问题。
范围
审计 是在 safe-smart-account 存储库中的 commit b115c4c 上进行的。 审计 的范围包括 contracts 目录中的所有 Solidity 文件，不包括 contracts/examples 和 contracts/test。
d89d156 最初用作目标 commit，但后来更新为包含 CompatibilityFallbackHandler 合约中的更改。
第二次修复审查是在 safe-smart-account 存储库中的 commit 5d26505 上进行的。
发现
安全发现的分类由两个等级确定：影响和可能性。 这种二维分类有助于明确各个问题的严重性。 如果某个问题的严重性被评为 中等，但可能仅由团队发现，则通常会因可能性因素而降低到 警告 或 信息性 严重性等级。
我们的审查发现了 19 个发现，范围从中等到中等严重性。 最严重的发现 M1 是通过手动引导的模糊测试发现的。 该问题揭示了一种抢跑攻击的可能性，攻击者可以代表用户部署新的 Safe，而无需执行预期的回调。 该问题存在于 SafeProxyFactory 中，而不是 Safe 帐户本身； 它涉及（现在已删除的）createProxyWithCallback 方法，并且没有现有的 Safe 受到影响。 该问题未通过早期的形式验证检查和之前的审计发现。
M1 问题已在所有受支持链的 1.4.1 版本（及更低版本）的已部署合约中发现。 Ackee Blockchain Security 在确定发现后立即通过安全通道启动了负责任的披露，以减轻任何可能的风险。 Safe 团队迅速承认了该发现的有效性，据他们称，该问题从未被利用过。 修复计划在 Safe 即将发布的 v1.5.0 版本中进行。
该代码有详细的文档，并解释了可能的注意事项和安全考虑因素。 在用户体验方面还有改进的空间（W1、W7、I4、I5）。 审阅版本的 Safe 与 EIP-7702 智能帐户不兼容。
严重程度
未发现严重程度的问题。
高严重性
未发现高严重性问题。
中等严重性
M1：在 Safe 部署期间，抢跑攻击可以绕过回调执行
低严重性
L1：CompatibilityFallbackHandler 不提供完全兼容性
L2：对 masterCopy 调用的严格 calldata 检查
警告严重性
W1：误导性的事件发出
W2：使用预先计算的 msg.data
W3：假定暂存空间已清零
W4：Safe setup 可能会发出过时的信息
W5：onlyNonceZero 检查可以被绕过
W6：锁定 token 的可能性
W7：ProxyCreationL2 nonce 值不是用户给定的参数
信息严重性
I1：文档问题
I2：不必要的类型转换为 payable
I3：代码优化
I4：工厂 initializer 错误未传播
I5：没有用于 FallbackManager 处理程序地址的 view 函数
I6：SafeStorage 可以定义为抽象
I7：缺少 createChainSpecificProxyWithNonce 的 L2 特定变体
I8：接口类型用于接受零地址的参数
I9：ChangedThreshold 事件无条件发出
信任模型
Safe 的所有者对 Safe 拥有完全控制权。 任何附加的模块都必须是可信的，因为它们可以从 Safe 执行任意交易。 附加的回退处理程序必须是可信的，因为它可以代表 Safe 验证 ERC-1271 签名。
可以信任 Safe 代理工厂在正确使用时提供抢跑保护。 也就是说，只要 Safe 设置作为代理部署的初始化步骤执行，就可以保证预先计算的 Safe 地址将属于预期的所有者。
结论
Ackee Blockchain Security 建议 Safe：
-
记录 Safe 帐户与 EIP-7702 不完全兼容；
-
清楚地将 contracts/examples 下的文件标记为非生产代码；
-
记录 CompatibilityFallbackHandler 不支持的功能； 并且
-
解决所有已确定的问题。
Ackee Blockchain Security 的完整 Safe 审计 报告可以在此处找到 。
我们一直很高兴与 Safe 的世界一流团队合作，并期待未来再次对他们进行审计。
