VFAT Sickle审计总结

  • Ackee
  • 发布于 2025-05-15 21:16
  • 阅读 19

VFAT是一个收益聚合器,使用Sickle智能合约钱包进行收益耕作。Ackee Blockchain Security对其协议进行了安全审查,发现了31个问题,从Informational到High severity不等。第二次安全审查主要针对第一次审查中发现的问题的修复。

VFAT 是一个收益聚合器,它使用 Sickle 智能合约钱包进行收益耕作。它将进入和退出仓位、复利或重新平衡等复杂操作简化为单笔交易。

VFAT 委托 Ackee Blockchain Security 对 VFAT 协议进行安全审查,总捐赠时间为 18 个工程日,时间为 2025 年 3 月 4 日至 3 月 28 日。第二次安全审查的重点是修复第一次安全审查中发现的问题;没有审计其他的代码变更。

我们感谢 Optimism 批准了一项赠款,部分资助了本次以及即将到来的第二次对 VFAT 的审计

方法论

我们首先使用静态分析工具(包括 Wake)开始审查。然后,我们深入研究了合约的逻辑。

在审查期间,我们特别注意:

  • 确保系统的算术运算正确;
  • 检测代码中可能存在的重入;
  • 检查 delegatecall 使用的安全性;
  • 确保访问控制不会过于宽松或过于严格;
  • 检查可升级性实现的正确性;以及
  • 寻找常见问题,例如数据验证。

范围

第一次审计是在 commit 357593f 上进行的,范围如下:

  • contracts/Automation.sol
  • contracts/ConnectorRegistry.sol
  • contracts/NftSettingsRegistry.sol
  • contracts/PositionSettingsRegistry.sol
  • contracts/Sickle.sol
  • contracts/SickleFactory.sol
  • contracts/SickleRegistry.sol
  • contracts/governance/SickleMultisig.sol
  • contracts/libraries/FeesLib.sol
  • contracts/libraries/NftSettingsLib.sol
  • contracts/libraries/NftTransferLib.sol
  • contracts/libraries/PositionSettingsLib.sol
  • contracts/libraries/SwapLib.sol
  • contracts/libraries/TransferLib.sol

为了完整起见,还有必要审查以下父合约:

  • base/Admin.sol
  • base/Multicall.sol
  • base/NonDelegateMulticall.sol
  • base/SickleStorage.sol
  • base/TimelockAdmin.sol

修复审查是在给定的 commit 1c20e7e 上完成的。

发现

安全发现的分类由两个评级决定:影响可能性。这种二维分类有助于阐明各个问题的严重性。如果某个问题的严重性被评为中等,但可能只会被团队发现,通常会因可能性因素而降低到警告信息性严重性评级。

我们的审查发现了 31 个发现,范围从信息性到高危。最严重的发现 H1 将允许管理员(恶意或被入侵)耗尽所有用户钱包。中等严重性问题 M1 允许抢先交易 setReferralCode 函数。大多数发现都是警告,指出了各种缺失的验证、代码质量问题和违反最佳实践的行为。

第二次安全审查仅限于第一次安全审查中发现的问题,未审计其他代码变更。20 个问题已修复,3 个问题部分修复,7 个问题已确认,VFAT 宣布 H1 无效。请在文章末尾链接的完整审计报告中阅读发现详情。

严重级别

未发现严重级别的问题。

高危级别

H1:白名单调用者可以对每个 Sickle 执行 delegatecall

中等严重程度

M1:推荐代码设置者可以被抢先交易

低等严重程度

L1:非合约注册表可能导致回滚

警告级别

W1:NFT 仓位的数据验证不完整

W2:重复的 Sickle 检索

W3:tick 范围计算中可能存在下溢或溢出

W4:变量遮蔽

W5:PositionSettingsRegistry 合约中的数据验证不足

W6:PositionSettingsRegistry 中的价格计算不正确

W7:Initializable 的使用不正确

W8:变量命名约定

W9:一步所有权转移

W10:feeTokens 数组中的重复 token 可能导致费用计算不一致

W11:FeesLib 合约中 ETH 和 WETH 的处理不一致

W12:SwapLib 合约中对原生值的处理含糊不清

W13:误导性的继承

W14:没有输入数组长度验证

W15:在注册表添加和更新时没有数据验证

W16:缺少零地址验证

信息级别

I1:重复代码

I2:使用魔法常量

I3:未整合的存储变量定义

I4:冗余存储变量

I5:映射 isCustomRegistry 是冗余的

I6:函数命名约定不一致

I7:函数注释中的印刷错误

I8:误导性的错误名称

I9:未使用的错误

I10:冗余函数

I11:缺少重复注册表验证

I12:文档中的错误

信任模型

协议要求用户信任控制关键参数(费用、白名单、Connector 更新)的管理员和代表他们执行操作的 Automator。虽然用户控制他们的 Sickle 实例和仓位设置,但系统仍然保持着中心化的控制点。信任风险通过硬编码的限制和多重签名要求得到部分缓解;但是,用户必须接受中心化控制和 Automator 可能操纵交易的风险,因为 Automator 可以控制交易时机。

结论

Ackee Blockchain Security 建议 VFAT:

  • 设置链下监控,用于 M1 发现中描述的目的;以及
  • 解决所有其他报告的问题。

Ackee Blockchain Security 的完整 VFAT Sickle 审计报告可以在 这里 找到。

我们很高兴能审计 VFAT,并期待再次与他们合作。

  • 原文链接: ackee.xyz/blog/vfat-sick...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
Ackee
Ackee
Cybersecurity experts | We audit Ethereum and Solana | Creators of @WakeFramework , Solidity (Wake) & @TridentSolana | Educational partner of Solana Foundation