任意调用 & Slitherin 新检测器发布

本文介绍了Pessimistic.io团队开发的Slitherin工具的最新版本,重点介绍了新增加的“Arbitrary Call”检测器,该检测器旨在帮助审计人员发现智能合约中潜在的任意外部调用风险。此外,文章还提到了Slitherin与AuditWizard.io的合作,以及Slitherin未来的发展计划。

任意调用 & 新的 Slitherin 检测器发布

Officer's Blog

各位读者,你们好! 今天,我们将在这篇文章中介绍与我们的 Slitherin 项目相关的重要新闻和更新。我们保证这将非常吸引人 —— Slitherin,我们自己的一套用于 Slither 的自定义检测器,又一个很棒的更新!

GitHub - pessimistic-io/slitherin: Pessimistic.io 的 Slither 检测器\ \ Pessimistic.io 的 Slither 检测器。通过在 GitHub 上创建一个帐户来为 pessimistic-io/slitherin 的开发做贡献。\ \ github.com

最近几个月,我们一直在积极开发我们 自己的 Slither 检测器,以帮助进行代码 审查 和审计过程。最近,我们发布了几个新的检测器,我们鼓励你将它们用于你的初始内部 审计,但现在让我们回到我们今天 对话 的重点。

简单来说,我们的检测器是对 checklist 中实现的检查的一种自动化,它们的主要目的是查找问题并协助代码审计员。今天,我们将 分解 我们的新 Arbitrary Call 检测器,并大致了解它是什么!

Release v0.3.0 · pessimistic-io/slitherin\ \ 主要更新\ 返工和添加\ \ pess-arbitrary-call 检测器:新检测器。感谢 @Yhtiyar\ \ 关键修复\ \ pess-strange-sette…\ \ github.com

在此期间,我们进行了一些重大更新,感谢大家的支持和关注。如果你通过我们的自定义 Slither 检测器发现了 问题/错误/漏洞,请告知我们。你可以通过打开 PR/Issue直接 联系我们,无论哪种方式对你来说更方便!

现在可以安装一个全新的软件包:pypi.org/project/slitherin

如果你有任何其他问题或建议,请 加入我们的 Discord 服务器Telegram 聊天。我们希望在那里见到你,并且我们打算支持社区及其 倡议

谢谢,让我们开始吧!


Arbitrary Call: 检测器

detector 迭代所有底层调用,检查目标或 calldata 是否可能被污染(manipulated)。有关检测器的所有信息如下。

检测器结构

  • 检查: pess-arbitrary-call

  • 严重性: High

  • 置信度: Low

  • 测试场景

一般建议:不要允许用户进行任意调用!

slitherin/docs/arbitrary_call.md at master · pessimistic-io/slitherin

Pessimistic.io 的 Slither 检测器。通过在 GitHub 上创建一个帐户来为 pessimistic-io/slitherin 的开发做贡献。

github.com

可能的改进: 过滤掉 role 保护的调用,将检测器划分为多个具有不同严重性和置信度的 detectors

如果你有任何其他问题或建议,请 加入我们的 Discord 服务器Telegram 聊天我们希望在那里见到你,并且我们打算支持社区及其倡议!


Arbitrary Call: 审计时

总体思路: 如果一个合约有 arbitrary 调用,它通常不应该包含 transfer/transferFrom/approve calls。如果合约中存在此类调用,则意味着该 contract 存储了 tokens 或它们的 approvals。因此,它们可以通过对 token 合约的 [arbitrary](https://consensys.github.io/smart-contract-best-practices/development-recommendations/general/external-calls/#:~:text=Solidity%20offers%20low%2Dlevel%20call,delegatecall()%20%2C%20and%20address.) 调用来窃取。

以下是我们的审计笔记,你将从中了解我们是如何提出这种检测器的想法,以及它实际上是什么。请务必仔细 study 它们!

Arbitrary Calls 分解

  • 存在对自定义地址的调用;

  • 存在带有 arbitrary calldata 的调用。

你需要检查什么

  • 你可以插入 token 的地址并调用函数 transfer/transferFrom/approve;

  • 你可以获得特权访问权限;

  • 你可以执行一个 reentrancy

  • 其他(订单填充、奇怪/非典型的 staking 等)

安全假设

  • Solidity 为 calling 其他合约中的函数提供了方便的高级语法,但只有在编译时知道目标合约interface 时,此高级语法才可用,read more here

  • 恶意合约可能会提取合约在响应外部调用到 arbitrary addresses 时的余额,从而导致资金损失。由于此缺陷,attackers 可以利用合约的 capabilities 来发挥自己的优势,并运行 malicious 或未经授权的代码,这些代码可以从合约中提取资产,或者破坏合约的工作机制,read more here

需要特别注意

  • 在我们的审计中,我们看到了不同的方法,例如 ActionOnBehalfOf — 它们需要各种 approvals,但允许你管理其他人的 staking 资金。这是一件非常罕见的事情,需要特别注意!

  • 除了通常的 transfer、transferFrom、approve 之外,还需要检查调用脚本/场景到相同的合约中;例如,在其中一个项目的代码中,存在 token staking (transferFrom(msg.sender, address(this), x)),但在提款时,可以指定接收者并在那里提款!

  • 以合约本身的名义调用。例如,你可以进入“受保护的”代码(绕过访问控制)3+4。你可以调用自己以使 msg.sender == this。例如,transferFrom(msg.sender, this, N);

  • Transfer 和 approve 可能允许从合约的余额中 withdraw tokens。并且 transferFrom 可能允许你窃取其他人的 tokens(使用对此合约的 approvals)。

你应该做什么

  • 如果可能,不要使用 arbitrary 调用;

  • 如果存在 arbitrary 调用,则合约不应存储 token approves;

  • 最好也创建一个层,向其授予 approve,并将必要的 tokens 抛给路由器;

  • 可选地,该层可以设置为 pausable 或添加 selfdestruct;

  • 尽量减少“最后一分钟”的编辑!

  • 尝试过滤用户提供的函数签名!

调用“自定义”地址

  • 通过 C1 合约中的 arbitrary 调用,可以调用 C2,C2 关心它是 C1 调用的。这绕过了 C2 中的 msg.sender 检查。例如,假设有一个由两个合约 C1 和 C2 组成的系统:

a) C1.foo() 进行 arbitrary 调用(除了可能还有其他操作);

b) C1.bar() 进行各种检查并调用 C2.xyz();

c) C2.xyz() 做一些非常重要的事情,并且受到 onlyC1 的保护,那么可以通过 C1.foo()->C2.xyz() 绕过 C1.bar 中的检查(onlyC1 不会注意到这个技巧);

  • 如果合约 A 在合约 A 上有资产(ether 或 tokens),并且合约 A 对“用户”合约 B 进行 delegatecall,则合约 B 可以从合约 A 的资产负债表中提取资产;

  • 我们不能排除不存在 tokens,但存在原生货币的情况。如果该项目位于特定链上,并且原生货币是预编译的合约(例如 Moonbeam 和 MOVR & GLMR tokens),则也可以对其执行 delegatecallVulnerability example

  • 在合约代码中使用 fallback() 函数时应非常小心。因此,在没有 revert 和条件的情况下存在 fallback() 函数允许为此合约执行具有合约源代码中未显示的任何签名的函数(可能是恶意的);

  • 潜在的 DoS: 该地址可以简单地丢弃或“eat”掉所有 gas,调用合约不应以某种方式滞后或因此而冻结(与 State Machine 模式相关)。也与 .send()\、`.transfer()`. 相关;

  • Delegatecall 到欺骗地址可能会删除调用合约或完全破坏存储;

  • 从 0.5 开始,编译器会插入对被调用地址的检查(它是 contract 而不是 EoA)。但对于底层调用(.call, .delegatecall 和其他)和 assembly 没有这样的检查。调用非合约地址不会产生任何错误,但逻辑甚至不会启动。

几个月前我们完成了自己的研究;如果你还没有阅读,请阅读:

Solidity Checklist & Reentrancy Attack\ \ Solidity Checklist & Reentrancy Attack\ \ 今天,我们将介绍在 Solidity 上智能合约开发期间进行审计的一些具体技巧!\ \ officercia.mirror.xyz


Slitherin X AuditWizard.io 合作

最近,一个专业的 IDE released — 并且它集成了我们的 Slitherin 工具!

Audit Wizard 是一个用于审计智能合约的一体化 platform。扫描 vulnerabilities,利用 AI 获取安全见解,生成审计报告等等。在 following 中阅读更多相关信息 Johnny Time

在本地或 via 试用我们的新检测器 auditwizard.io 替代方案(实际上非常棒!) UI:

github.com

github.com

auditwizard.io中,来自依赖项的结果也已从 Slither 中过滤掉,以删除不必要的结果。Slitherin,的扩展版本 Slither 伴随 even 更多 vulnerability 检测器,也已添加以增加扫描器的覆盖率:

我们对这次合作感到非常兴奋,并希望看到 Slitherin 以更多方式使用!在不久的将来,我们打算在大量的 Slitherin & Spotter 推介 conferences,也为:

我们还通过 Arbitrum 授权生态系统申请了专业的检测器,我们正在计划另外两个项目。如果你有兴趣,请联系我们!


Slitherin Timeline 3.0

在此期间,我们进行了一些重大更新,感谢大家的支持和关注。如果你通过我们的自定义 Slither 检测器发现了 问题/错误/漏洞,请告知我们。

Slitherin Timeline 2.0\ \ Slitherin Timeline 2.0\ \ 各位读者,你们好!今天,我们将介绍与我们的 Slitherin 项目相关的重要新闻和更新!\ \ officercia.mirror.xyz

你可以通过打开 PR/Issuedirectly 联系我们,无论哪种方式对你来说更方便!

Slitherin 3.0 更新

主要更新、返工、添加、小修小补和优化:

  1. pess-arbitrary-call 检测器:新检测器。谢谢 Yhtiyar

  2. pess-strange-setter 检测器:不再检测没有参数的函数。谢谢 @Yhtiyar;

  3. pess-unprotected-setter detector: 现在有一个单独的测试文件;

  4. Release Note.

如果你有任何其他问题或建议,请 加入我们的 Discord 服务器Telegram 聊天。我们希望在那里见到你,并且我们打算支持社区及其倡议。谢谢!


我们的团队还要对 Slither tool 的创建者表示最深切的感谢:Josselin Feist、Gustavo Grieco 和 Alex Groce,以及 CryticTrail of Bits' 区块链安全部门,以及所有相信 original 工具及其发展的人们!

我们真诚地希望你发现我们的工作有用,并感谢任何反馈,所以请随时 contact us! The best answers and questions may be included in the next blog post. 我们希望这篇文章对你来说内容丰富且有用!

注意安全!


支持对我来说非常重要,有了它,我可以做我喜欢的事情 —— 教育用户!

GitHub - OffcierCia/support: SupportMe

SupportMe. Contribute to OffcierCia/support development by creating an account on GitHub.

github.com

如果你想支持我的工作,请考虑向我捐款:

注意安全!

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

0 条评论

请先 登录 后评论
officercia
officercia
江湖只有他的大名,没有他的介绍。