Prepared by:
HALBORN
Last Updated 10/22/2024
Date of Engagement by: July 29th, 2024 - October 1st, 2024
Summary
100% of all REPORTED Findings have been addressed
All findings
3
Critical
0
High
0
Medium
0
Low
0
Informational
3
Table of Contents
- 1. Introduction
- 2. Assessment summary
- 3. Test approach and methodology
- 4. Risk methodology
- 5. Scope
- 6. Assessment summary & findings overview
- 7. Findings & Tech Details
- 7.1 State authority can withdraw tokens without restrictions
- 7.2 Proof length as env variable risks token claim failures
- 7.3 Possibility to use incorrect mint to claim tokens
- 8. Automated Testing
1. Introduction
deBridge engaged Halborn to conduct a security assessment on their updated Claiming Solana program beginning on 07/29/2024, and ending on 01/10/2024. The security assessment was scoped to the Solana Programs provided in points-claimer-solana GitHub repository. Commit hashes and further details can be found in the Scope section of this report.
The Claiming Program allows users to claim tokens based on their point score, supporting addresses from both Solana and Ethereum Virtual Machine (EVM) chains. The eligibility and amount of tokens that can be claimed are defined in a data source which specifies the addresses and their corresponding claimable amounts. The program uses a Merkle tree for secure and efficient verification of claims.
The deBridge team provided three updated versions of the program. The first updated version of the claiming program introduces several new features:
The program authority can now create multiple "seasonal" allocations, allowing users to claim their tokens after specific start slots.
The program authority can also blacklist specific users for a given season.
The terms and conditions of signature verification for Solana users were modified.
The code base has been refactored and modularized into multiple files.
The second updated version adds the following feature to the program:
The claim instruction using EVM address now has full and short variants of terms to be signed.
The third updated version introduces only minor, non-functional changes.
2. Assessment Summary
Halborn was provided 5 weeks for the engagement and assigned one full-time security engineer to review the security of the Solana Programs in scope. The engineer is a blockchain and smart contract security expert with advanced smart contract hacking skills, and deep knowledge of multiple blockchain protocols.
The purpose of the assessment is to:
Identify potential security issues within the Solana Programs.
Ensure that smart contract functionality operates as intended.
In summary, Halborn did not identify any major security concerns and all informational issues have been acknowledged and addressed by deBridge team. The informational issue "Possibility to use incorrect mint to claim tokens" has been addressed and solved.
The remaining two informational issues were acknowledged:
Proof length as env variable risks token claim failures
State authority can withdraw tokens without restrictions
3. Test Approach and Methodology
Halborn performed a combination of a manual review of the source code and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of the program assessment. While manual testing is recommended to uncover flaws in business logic, processes, and implementation; automated testing techniques help enhance coverage of programs and can quickly identify items that do not follow security best practices.
The following phases and associated tools were used throughout the term of the assessment:
- Research into the architecture, purpose, and use of the platform.
- Manual program source code review to identify business logic issues.
- Mapping out possible attack vectors
- Thorough assessment of safety and usage of critical Rust variables and functions in scope that could lead to arithmetic vulnerabilities.
- Scanning dependencies for known vulnerabilities (`cargo audit`).
- Local Anchor testing (`anchor test`)
4. RISK METHODOLOGY
4.1 EXPLOITABILITY
Attack Origin (AO):
Attack Cost (AC):
Attack Complexity (AX):
Metrics:
| EXPLOITABILIY METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Attack Origin (AO) | Arbitrary (AO:A) Specific (AO:S) | 1 0.2 |
| Attack Cost (AC) | Low (AC:L) Medium (AC:M) High (AC:H) | 1 0.67 0.33 |
| Attack Complexity (AX) | Low (AX:L) Medium (AX:M) High (AX:H) | 1 0.67 0.33 |
4.2 IMPACT
Confidentiality (C):
Integrity (I):
Availability (A):
Deposit (D):
Yield (Y):
Metrics:
| IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Confidentiality (C) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
| Integrity (I) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
| Availability (A) | None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C) | 0 0.25 0.5 0.75 1 |
| Deposit (D) | None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C) | 0 0.25 0.5 0.75 1 |
| Yield (Y) | None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C) | 0 0.25 0.5 0.75 1 |
4.3 SEVERITY COEFFICIENT
Reversibility (R):
Scope (S):
Metrics:
| SEVERITY COEFFICIENT () | COEFFICIENT VALUE | NUMERICAL VALUE |
|---|---|---|
| Reversibility () | None (R:N) Partial (R:P) Full (R:F) | 1 0.5 0.25 |
| Scope () | Changed (S:C) Unchanged (S:U) | 1.25 1 |
| Severity | Score Value Range |
|---|---|
| Critical | 9 - 10 |
| High | 7 - 8.9 |
| Medium | 4.5 - 6.9 |
| Low | 2 - 4.4 |
| Informational | 0 - 1.9 |
5. SCOPE
- debridge-finance/points-claimer-solana/blob/main/programs/points-claimer/Cargo.toml
- debridge-finance/points-claimer-solana/blob/main/programs/points-claimer/Xargo.toml
- debridge-finance/points-claimer-solana/blob/main/programs/points-claimer/build.rs
- debridge-finance/points-claimer-solana/blob/main/programs/points-claimer/Cargo.toml
- debridge-finance/points-claimer-solana/blob/main/programs/points-claimer/Xargo.toml
- debridge-finance/points-claimer-solana/blob/main/programs/points-claimer/build.rs
- debridge-finance/points-claimer-solana/blob/main/programs/points-claimer/Cargo.toml
- debridge-finance/points-claimer-solana/blob/main/programs/points-claimer/Xargo.toml
- debridge-finance/points-claimer-solana/blob/main/programs/points-claimer/build.rs
6. Assessment Summary & Findings Overview
Critical
0
High
0
Medium
0
Low
0
Informational
3
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| State authority can withdraw tokens without restrictions | Informational | Acknowledged |
| Proof length as env variable risks token claim failures | Informational | Acknowledged |
| Possibility to use incorrect mint to claim tokens | Informational | Solved - 08/06/2024 |
7. Findings & Tech Details
7.1 State authority can withdraw tokens without restrictions
// Informational
Description
The Claiming Program allows users to claim tokens based on their point score. The tokens are held in a treasury account until they are transferred to eligible users.
The instruction Withdraw enables the state authority to withdraw the full amount of tokens from the treasury to prevent any unclaimed tokens to be stuck. However, the Withdraw instruction can be invoked by the state authority at any time. If used inappropriately, users will be unable to claim their tokens.
lib.rs
#[derive(Accounts, AccountsCount)]
#[instruction(
season: u8,
)]
pub struct Withdraw<'info> {
#[account(
seeds = [&SeasonalState::seed(season)],
bump = state.bump,
constraint = state.season_number == season,
)]
pub state: Account<'info, SeasonalState>,
#[account(
mut,
token::mint = mint,
token::authority = state,
token::token_program = token_program,
)]
pub treasury: InterfaceAccount<'info, TokenAccount>,
#[account(
mut,
token::mint = mint,
token::token_program = token_program,
)]
pub dest_token_acc: InterfaceAccount<'info, TokenAccount>,
mint: InterfaceAccount<'info, Mint>,
pub token_program: Interface<'info, TokenInterface>,
state_authority: Signer<'info>,
#[account(
constraint = program.programdata_address()?
== Some(program_data.key()) @ Error::WrongProgram,
)]
program: Program<'info, PointsClaimer>,
#[account(
constraint = program_data.upgrade_authority_address
== Some(state_authority.key()) @ Error::WrongProgramAuthority,
)]
program_data: Account<'info, ProgramData>,
}
pub fn withdraw(ctx: Context<Withdraw>) -> Result<()> {
token_interface::transfer_checked(
CpiContext::new_with_signer(
ctx.accounts.token_program.to_account_info(),
token_interface::TransferChecked {
from: ctx.accounts.treasury.to_account_info(),
mint: ctx.accounts.mint.to_account_info(),
authority: ctx.accounts.state.to_account_info(),
to: ctx.accounts.dest_token_acc.to_account_info(),
},
&[&[
&SeasonalState::seed(ctx.accounts.state.season_number),
&[ctx.accounts.state.bump],
]],
),
ctx.accounts.treasury.amount,
ctx.accounts.mint.decimals,
)?;
token_interface::close_account(CpiContext::new_with_signer(
ctx.accounts.token_program.to_account_info(),
token_interface::CloseAccount {
account: ctx.accounts.treasury.to_account_info(),
destination: ctx.accounts.dest_token_acc.to_account_info(),
authority: ctx.accounts.state.to_account_info(),
},
&[&[
&SeasonalState::seed(ctx.accounts.state.season_number),
&[ctx.accounts.state.bump],
]],
))?;
Ok(())
}Proof of Concept
Create a new season with a given Merkle root.
Claim tokens using valid MT proof.
Withdraw tokens from the treasury.
BVSS
Recommendation
To address this issue, it is recommended to implement a mechanism to prevent unconditional withdrawal from the treasury, such as using a multisig account owned by multiple parties as the state authority, or adding a minimum time period after which token withdrawals will be possible.
Remediation
ACKNOWLEDGED: The deBridge team confirmed that a multisig authority will be used as the program upgrade authority and therefore the state and withdraw authority. This reduces the risk of incorrect or unauthorized withdrawals.
7.2 Proof length as env variable risks token claim failures
// Informational
Description
The length of Merkle tree proof can be defined as an environmental variable that is not stored in version control. After building and deploying the program, it won't be possible to track down the proof length set during deployment. Setting the length incorrectly will result in users being unable to claim their tokens and necessity to redeploy the program.
constants.rs
pub const PROOF_LEN: usize = option::unwrap_or!(
option::and_then!(option_env!("PROOF_LEN"), |str| result::ok!(parse_usize(
str
))),
19
);BVSS
Recommendation
To address this issue, it is recommended to use a configuration file that can be stored in a version control system.
Remediation
ACKNOWLEDGED: The deBridge team acknowledged the issue.
7.3 Possibility to use incorrect mint to claim tokens
// Informational
Description
The claimSolana and claimEvm instructions enable users to claim their tokens based on their point score.
Although unlikely, it is possible to invoke both claim instructions with an incorrect mint account and the corresponding treasury and receiver token accounts. This would consequently disable the possibility to claim tokens with the correct mint.
claim_solana.rs
pub struct ClaimSolana<'info> {
#[account(
seeds = [&SeasonalState::seed(season)],
bump = state.bump,
constraint = state.is_working @ Error::StatePaused,
constraint = amount <= state.max_drop_per_ix @ Error::MaxDropPerIxViolation,
constraint = state.starting_slot <= Clock::get()?.slot @ Error::SlotUnderflow,
constraint = state.season_number == season,
)]
state: Account<'info, SeasonalState>,
#[account(
mut,
token::mint = mint,
token::authority = state,
token::token_program = token_program,
has_one = mint,
)]
treasury: InterfaceAccount<'info, TokenAccount>,
#[account(
init_if_needed,
payer = points_owner,
associated_token::mint = mint,
associated_token::authority = receiver,
associated_token::token_program = token_program,
)]
receiver_token_acc: InterfaceAccount<'info, TokenAccount>,
mint: InterfaceAccount<'info, Mint>,
#[account(
init,
seeds = [b"receipt", &[season][..], &points_owner.key().to_bytes()],
bump,
payer = points_owner,
space = 8 + Receipt::INIT_SPACE,
)]
receipt: Account<'info, Receipt>,
/// CHECK: signature will be checked in handler
receiver: AccountInfo<'info>,
system_program: Program<'info, System>,
token_program: Interface<'info, TokenInterface>,
associated_token_program: Program<'info, AssociatedToken>,
/// CHECK: will be processed in the handler
ban_marker: AccountInfo<'info>,
#[account(mut)]
points_owner: Signer<'info>,
}claim_evm.rs
pub struct ClaimEvm<'info> {
#[account(
seeds = [&SeasonalState::seed(season)],
bump = state.bump,
constraint = state.is_working @ Error::StatePaused,
constraint = amount <= state.max_drop_per_ix @ Error::MaxDropPerIxViolation,
constraint = state.starting_slot <= Clock::get()?.slot @ Error::SlotUnderflow,
constraint = state.season_number == season,
)]
state: Account<'info, SeasonalState>,
#[account(
mut,
token::mint = mint,
token::authority = state,
token::token_program = token_program,
has_one = mint,
)]
treasury: InterfaceAccount<'info, TokenAccount>,
#[account(
init_if_needed,
payer = payer,
associated_token::mint = mint,
associated_token::authority = receiver,
associated_token::token_program = token_program,
)]
receiver_token_acc: InterfaceAccount<'info, TokenAccount>,
mint: InterfaceAccount<'info, Mint>,
#[account(
init,
seeds = [b"receipt", &[season][..], &address],
bump,
payer = payer,
space = 8 + Receipt::INIT_SPACE,
)]
receipt: Account<'info, Receipt>,
/// CHECK: can be any account
receiver: AccountInfo<'info>,
#[account(mut)]
payer: Signer<'info>,
system_program: Program<'info, System>,
token_program: Interface<'info, TokenInterface>,
associated_token_program: Program<'info, AssociatedToken>,
/// CHECK: will be processed in the handler
ban_marker: AccountInfo<'info>,
}Proof of Concept
Create season 0 using mintA.
Create a new mintB where the authority is the season 0 PDA and corresponding treasury.
Claim solana using mintB.
Claim solana using mintA.
BVSS
Recommendation
To address this issue, it is recommended to require using the same mint as saved in the seasonal state account.
Remediation
SOLVED: The deBridge team solved the issue by adding the has_one = mint anchor constraints in the ClaimSolana and ClaimEvm instruction contexts to ensure only the expected mint is used
Remediation Hash
8. Automated Testing
Static Analysis Report
Description
Halborn used automated security scanners to assist with detection of well-known security issues and vulnerabilities. Among the tools used was cargo audit, a security scanner for vulnerabilities reported to the RustSec Advisory Database. All vulnerabilities published in https://crates.io are stored in a repository named The RustSec Advisory Database. cargo audit is a human-readable version of the advisory database which performs a scanning on Cargo.lock. Security Detections are only in scope. All vulnerabilities shown here were already disclosed in the above report. However, to better assist the developers maintaining this code, the auditors are including the output with the dependencies tree, and this is included in the cargo audit output to better know the dependencies affected by unmaintained and vulnerable crates.
Cargo Audit Results
ID | Crate | Description |
|---|---|---|
RUSTSEC-2024-0344 | curve25519-dalek | Timing variability in |
RUSTSEC-2022-0093 | curve25519-dalek | Double Public Key Signing Function Oracle Attack on |
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
Table of Contents
- 1. Introduction
- 2. Assessment summary
- 3. Test approach and methodology
- 4. Risk methodology
- 5. Scope
- 6. Assessment summary & findings overview
- 7. Findings & Tech Details
- 7.1 State authority can withdraw tokens without restrictions
- 7.2 Proof length as env variable risks token claim failures
- 7.3 Possibility to use incorrect mint to claim tokens
- 8. Automated Testing
// Download the full report
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed