Recently, using X-Ray we identified a vulnerability in an on-chain Solana smart contract (jet-v1) and have been awarded a bug bounty through Immunefi. We thank the Jet Protocol team and Immunefi for their quick responses and generous support. The fix has been applied in this commit.

This article shares our bug hunting experience with X-Ray.

What is X-Ray?

X-Ray is an automated verification tool powered by the GreenCore technology. It scans the contract source code and looks for common pitfalls such as missing ownership check, missing signer check, Solana account confusions, arbitrary signed program invocation, and integer overflow/underflows.

X-Ray is currently under active development and checkers for more vulnerabilities are being added. More details and a tutorial could be found in [X-Ray — A vulnerability scanner for Solana smart contracts].

Shortlisting potential vulnerabilities using X-Ray

X-Ray is integrated with the contract build process. Getting a list of potential defects is as simple as one command line.

Suppose we have already obtained a fresh copy of a contract. We just need to invoke X-Ray . or x-ray -analyzeAll . in the Solana program’s directory where the build configuration file Xargo.toml exists.

The analysis is pretty fast and X-Ray will report a list of issues, which we may want to take a closer look at. In our scenario, among the four issues reported by X-Ray, the following two are particularly interesting.

[Issue-1] Unsafe Arithmetic Operation

[Issue-2] Unsafe Arithmetic Operation

In the above, X-Ray reports the issue types, issue locations, and the stack traces demonstrating how the issues may happen. The next step is to review the code and figure out if those issues can lead to security exploits.

Manual review

[Issue-1] Unsafe Arithmetic Operation

The types of collaterals and loans are both usize . If there are too many loans in the list, the indicated add operation can overflow. So, this is a true positive in theory. However, the exploit depends on the state instead of user input. Since it's not (directly) user-controllable, it's not an ideal candidate for exploit PoC (Proof of Concept) creation.

[Issue-2] Unsafe Arithmetic Operation

In borrow.rs, the computation of the total token amount Y for a borrow request of amount X can overflow. The possible consequences of this overflow are

1. A large amount (requested loan amount X) will be subtracted from the total_deposits in reserve, although only a small amount (Y because of the overflow) is eventually loaned to the borrower. The amount of X-Y in total_deposits will be lost.
2. After a successful loan transaction, a borrower who requests a large amount X may actually receive a small amount loan Y.

In particular:

• The value of amount (https://github.com/jet-lab/jet-v1/blob/109eb1c558a07ccdd77d6d8da382c7042255c5df/programs/jet/src/instructions/borrow.rs#L109) is from clients and thus can be anything.
• req_tokens(https://github.com/jet-lab/jet-v1/blob/109eb1c558a07ccdd77d6d8da382c7042255c5df/programs/jet/src/instructions/borrow.rs#L120) can be a very large number.
• The add operation +(https://github.com/jet-lab/jet-v1/blob/109eb1c558a07ccdd77d6d8da382c7042255c5df/programs/jet/src/instructions/borrow.rs#L122) can overflow. As a result, token_amount (type u64) in the same line will be a small positive number.
• The amount subtracted from the reserve total_deposits(https://github.com/jet-lab/jet-v1/blob/109eb1c558a07ccdd77d6d8da382c7042255c5df/programs/jet/src/state/reserve.rs#L255) is the large requested token amount, while the loan amount the borrower actually receives is a small positive number due to the overflow. As a result, some fund is lost.
• The actual loan amount token_amount(https://github.com/jet-lab/jet-v1/blob/109eb1c558a07ccdd77d6d8da382c7042255c5df/programs/jet/src/instructions/borrow.rs#L159) can be a small positive number and inconsistent with the large loan amount requested. Therefore, the contract doesn’t deliver the promised results.

PoC creation

Finding the appropriate inputs and satisfying all sanity checks in the contract are the main challenges for the PoC creation. In our scenario, we have to prepare appropriate deposit and collateral amounts to make the smart contract happy. After a few attempts, we found the magic numbers, and the following screenshot demonstrates the overflow and the loss of the holdings in the reserve total_deposits.

• The customer requested to borrow `18,428,315,757,952,000,000`. An additional fee (`0.1%`) of `18,428,315,757,952,000` will be required to process the borrow request.
• However, the largest number that can be represented by u64 is `18,446,744,073,709,551,615`. So, an overflow will occur in `token_amount = req_tokens + fees`, which gives a relative small number `400,384`.
• After a successful transaction, `18,428,315,757,952,000,000` was requested but `400,384` was received by the borrower.
• More importantly, the `total_deposits` was deducted by the amount requested instead of the actual amount borrowed. In other words, after borrowing `400,284`, the total holdings in the reserve decreased from `18,440,000,000,000,000,000` to `11,684,242,048,000,000`, which is inconsistent and a huge loss.

Developer response

We reported our findings together with a PoC to the developers. The developers acknowledged our findings with a reward and commented

“…although this is not exploitable in our program as deployed, and in general requires an improbable concentration of token supply in Jet’s reserves, it is a problem in principle, that we will patch, and review the rest of the codebase for other instances of.

We genuinely appreciate the time spent analyzing our code.”

The issue has been patched shortly after the report.

Takeaways

1. The initial automated verification by X-Ray is highly effective to filter out unimportant code and produce a shortlist of potential issues that require more attention, which saved significant manual audit time in our experience.
2. Generating penetration tests is challenging as it usually requires some knowledge of the logic in the smart contract. However, extra automation like symbolic execution or fuzzing could be done to reduce manual efforts.

For all blogs by X-Ray, Please visit https://www.sec3.dev/blog