使用X-Ray进行Solana漏洞赏金狩猎

最近，我们使用 X-Ray 发现了一个在链上的 Solana 智能合约（ jet-v1）中的漏洞，并通过 Immunefi 获得了错误赏金。我们感谢 Jet Protocol 团队和 Immunefi 的快速响应和慷慨支持。修复已应用于 此提交。

本文分享了我们使用 X-Ray 的错误猎捕体验。

什么是 X-Ray？

X-Ray 是一个由 GreenCore 技术 支持的自动化验证工具。它扫描合约的源代码，寻找常见的陷阱，如 缺少所有权检查、缺少签名检查、Solana 账户混淆、任意签名程序调用和 整数溢出/下溢。

X-Ray 目前正在积极开发中，更多漏洞检查器正在添加中。更多细节和教程可以在 [ X-Ray — Solana 智能合约的漏洞扫描器] 中找到。

使用 X-Ray 短名单潜在漏洞

X-Ray 集成在合约构建过程中。获取潜在缺陷列表只需一个命令行。

假设我们已经获得了合约的新副本。我们只需在存在构建配置文件 Xargo.toml 的 Solana 程序目录中调用 X-Ray . 或 x-ray -analyzeAll .

分析速度非常快，X-Ray 将报告一系列问题，我们可以进一步查看。在我们的情况下，在 X-Ray 报告的四个问题中，以下两个特别有趣。

[问题-1] 不安全的算术操作

[问题-2] 不安全的算术操作

在上面的内容中，X-Ray 报告了问题类型、问题位置以及演示问题可能发生的堆栈跟踪。下一步是审查代码并找出这些问题是否会导致安全漏洞。

手动审查

[问题-1] 不安全的算术操作

抵押品和贷款的类型都是 usize。如果列表中的贷款过多，指示的加法操作可能会溢出。因此，从理论上讲，这是真阳性。然而，漏洞取决于状态而不是用户输入。由于它不是（直接）用户可控的，因此它不是适合漏洞概念验证（PoC）创建的理想候选项。

[问题-2] 不安全的算术操作

在 borrow.rs 中，借款请求金额 X 的总Token金额 Y 的计算可能会溢出。此溢出的潜在后果包括：

1. 大笔金额（请求的贷款金额 X）将从储备的 total_deposits 中扣除，尽管最终只借给借款人的金额很小（Y 因溢出）。total_deposits 中的 X-Y 将会丢失。
2. 在成功的贷款交易后，申请大额 X 的借款人可能实际上会收到小额贷款 Y。

特别地：

• amount 的值（ https://github.com/jet-lab/jet-v1/blob/109eb1c558a07ccdd77d6d8da382c7042255c5df/programs/jet/src/instructions/borrow.rs#L109）来自客户端，因此可以是任何值。
• req_tokens（ https://github.com/jet-lab/jet-v1/blob/109eb1c558a07ccdd77d6d8da382c7042255c5df/programs/jet/src/instructions/borrow.rs#L120）可能是一个非常大的数字。
• 加法操作 +（ https://github.com/jet-lab/jet-v1/blob/109eb1c558a07ccdd77d6d8da382c7042255c5df/programs/jet/src/instructions/borrow.rs#L122）可能会溢出。因此，同一行中的 token_amount（类型 u64）将变成很小的正数。
• 从储备中扣除的 total_deposits（ https://github.com/jet-lab/jet-v1/blob/109eb1c558a07ccdd77d6d8da382c7042255c5df/programs/jet/src/state/reserve.rs#L255）是请求的总Token金额，而借款人实际收到的贷款金额由于溢出而变成小的正数。因此，一些资金丢失了。
• 实际贷款金额 token_amount（ https://github.com/jet-lab/jet-v1/blob/109eb1c558a07ccdd77d6d8da382c7042255c5df/programs/jet/src/instructions/borrow.rs#L159）可能是一个小的正数，并与请求的大额贷款金额不一致。因此，合约没有交付承诺的结果。

PoC 创建

找到适当的输入并满足合约中的所有健全性检查是 PoC 创建的主要挑战。在我们的情况下，我们必须准备适当的存款和抵押金额，以使智能合约满意。经过几次尝试，我们找到了神奇的数字，以下截图演示了溢出以及在储备 total_deposits 中的持有损失。

• 客户请求借款 ` 18,428,315,757,952,000,000 `。处理借款请求需要额外的费用（` 0.1% `），即 ` 18,428,315,757,952,000 `。
• 然而，u64 可以表示的最大数字是 ` 18,446,744,073,709,551,615 `。因此，` token_amount = req_tokens + fees ` 中将发生溢出，结果是相对较小的数字 ` 400,384 `。
• 在成功的交易后，申请的 ` 18,428,315,757,952,000,000 ` 被请求但借款人收到的却是 ` 400,384 `。
• 更重要的是，`total_deposits` 是根据请求的金额扣除的，而不是实际借出的金额。换句话说，在借出 ` 400,284 ` 后，储备中的总持有量从 ` 18,440,000,000,000,000,000 ` 减少到 ` 11,684,242,048,000,000 `，这并不一致，损失巨大。

开发者响应

我们与开发者报告了我们的发现和 PoC。开发者承认了我们的发现，并给予了奖励，并表示：

“……虽然这在我们已部署的程序中并不可被利用，并且通常需要在 Jet 的储备中不太可能的代币供应集中，但原则上这是一个问题，我们将进行补丁，并审查整个代码库中是否存在其他实例。”

“我们非常感谢你花时间分析我们的代码。”

在报告后不久，该问题已被修复。

收获

1. X-Ray 的初始自动化验证非常有效，可以过滤掉不重要的代码，生成需要更多关注的潜在问题的短名单，这在我们的经验中节省了大量的手动审核时间。
2. 生成渗透测试具有挑战性，因为它通常需要对智能合约中的逻辑有一些了解。然而，额外的自动化，如符号执行或模糊测试，可以减少手动工作量。

有关 X-Ray 的所有博客，请访问 https://www.sec3.dev/blog

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