Solana Contracts - deBridge

Prepared by:

HALBORN

Last Updated 04/26/2024

Date of Engagement by: November 28th, 2022 - December 16th, 2022

Summary

0% of all REPORTED Findings have been addressed

All findings

Critical

High

Medium

Low

Informational

1. Introduction
2. Audit summary
3. Test approach & methodology
4. Scope
5. Risk methodology
6. Scope
7. Assessment summary & findings overview
8. Findings & Tech Details

8.1 Fees can negate send amount

9. Automated Testing

1. INTRODUCTION

deBridge is a cross-chain interoperability and liquidity transfer protocol that allows decentralized transfer of assets between various blockchains. The cross-chain intercommunication of deBridge programs is powered by the network of independent oracles/validators which are elected by deBridge governance.

\client engaged Halborn to conduct a security audit on their Solana programs beginning on 2022-11-28 and ending on 2022-12-16. The security assessment was scoped to the programs provided in the Solana Contracts GitHub repository. Commit hashes and further details can be found in the Scope section of this report.

2. AUDIT SUMMARY

The team at Halborn was provided N weeks for the engagement and assigned M full-time security engineer/engineers to audit the security of the programs in scope. The security engineer/engineers is/are (a) blockchain and smart contract security expert/experts with advanced penetration testing and smart contract hacking skills, and deep knowledge of multiple blockchain protocols.

The purpose of this audit is to:

Identify potential security issues within the programs

In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which should be addressed by \client. The main one is the following:

Fees can negate the send amount.

3. TEST APPROACH & 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 audit. 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 audit:

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.
Finding unsafe Rust code usage (cargo-geiger)
Scanning dependencies for known vulnerabilities (cargo audit).
Local runtime testing (solana-test-framework)

4. SCOPE

Code repositories:

Project Name
Repository: Solana Contracts
Commit ID: d9fba17ee028db017af601dccf33e82c48a8b251
Programs in scope:
1. Debride (programs/debridge)
2. Debride Settings (programs/settings)
Debride (programs/debridge)
Debride Settings (programs/settings)

Out-of-scope:

third-party libraries and dependencies
financial-related attacks

5. RISK METHODOLOGY

Vulnerabilities or issues observed by Halborn are ranked based on the risk assessment methodology by measuring the LIKELIHOOD of a security incident and the IMPACT should an incident occur. This framework works for communicating the characteristics and impacts of technology vulnerabilities. The quantitative model ensures repeatable and accurate measurement while enabling users to see the underlying vulnerability characteristics that were used to generate the Risk scores. For every vulnerability, a risk level will be calculated on a scale of 5 to 1 with 5 being the highest likelihood or impact.

RISK SCALE - LIKELIHOOD

5 - Almost certain an incident will occur.
4 - High probability of an incident occurring.
3 - Potential of a security incident in the long term.
2 - Low probability of an incident occurring.
1 - Very unlikely issue will cause an incident.

RISK SCALE - IMPACT

5 - May cause devastating and unrecoverable impact or loss.
4 - May cause a significant level of impact or loss.
3 - May cause a partial impact or loss to many.
2 - May cause temporary impact or loss.
1 - May cause minimal or un-noticeable impact.

The risk level is then calculated using a sum of these two values, creating a value of 10 to 1 with 10 being the highest level of security risk.

Critical

High

Medium

Low

Informational

10 - CRITICAL
9 - 8 - HIGH
7 - 6 - MEDIUM
5 - 4 - LOW
3 - 1 - VERY LOW AND INFORMATIONAL

6. SCOPE

Out-of-Scope: New features/implementations after the remediation commit IDs.

7. Assessment Summary & Findings Overview

Critical

High

Medium

Low

Informational

Impact x Likelihood

Likelihood

Impact

HAL-01

Security analysis	Risk level	Remediation Date
FEES CAN NEGATE SEND AMOUNT	Informational	-

8. Findings & Tech Details

8.1 FEES CAN NEGATE SEND AMOUNT

// Informational

Description

The debridge programs allows users to send tokens to other chains with the send instruction. The fix_fee, transfer_fee and execution_fee charged to the user can be equivalent to the original amount of tokens sent, resulting in the final_amount of tokens the user receives on the other chain to be zero.

Code Location

programs/debridge/src/lib.rs

pub fn send(
    ctx: Context<Sending>,
    target_chain_id: [u8; 32],
    receiver: Vec<u8>,
    is_use_asset_fee: bool,
    amount: u64,
    submission_params: Option<SendSubmissionParamsInput>,
    referral_code: Option<u32>,
) -> Result<()> {
    let mut transfer_builder = Box::new(events::TransferredBuilder::default());
    transfer_builder.referral_code(referral_code);

    {
        let chain_address_len = ctx
            .accounts
            .bridge_ctx
            .chain_support_info
            .get_chain_address_len(&target_chain_id)?;
        require!(
            receiver.len().eq(&chain_address_len),
            DebridgeErrorCode::WrongReceiverAddress,
        );
        require!(
            submission_params
                .as_ref()
                .map(|param| param.fallback_address.len().eq(&chain_address_len))
                .unwrap_or(true),
            DebridgeErrorCode::WrongFallbackAddress,
        );
    }

    let fee_type = FeeType::new(is_use_asset_fee);
    let send_fix_fee = Box::new(ctx.accounts.get_fix_fee_sender(fee_type));
    let send_transfer_fee = Box::new(ctx.accounts.get_transfer_fee_sender());
    let process_exectuion_fee = Box::new(ctx.accounts.get_bridge_balance_changer());

    let final_amount = ctx
        .accounts
        .get_amount_context(
            ctx.accounts.send_token(amount)?,
            submission_params
                .as_ref()
                .map(|params| params.execution_fee),
            &target_chain_id,
        )?
        .take_fix_fee(send_fix_fee.add_pre_process(|fee| {
            transfer_builder.collected_fee(fee);
            Ok(())
        }))?
        .take_transfer_fee(|transfer_fee| {
            transfer_builder.collected_transfer_fee(transfer_fee);
            send_transfer_fee(transfer_fee)
        })?
        .process_amount_at_bridge(process_exectuion_fee)?
        .take_execution_fee(|execution_fee| {
            transfer_builder.execution_fee(execution_fee);
        })
        .amount();

Score

Impact: 1
Likelihood: 1

9. Automated Testing

AUTOMATED ANALYSIS

Description

Halborn used automated security scanners to assist with the 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.

Results

\begin{center} \begin{tabular}{|l|l|l|} \hline \textbf{ID} & \textbf{package} & \textbf{short description} \ \hline \href{https://rustsec.org/advisories/RUSTSEC-2020-0071}{RUSTSEC-2020-0036} & time & Potential segfault \ \hline \href{https://rustsec.org/advisories/RUSTSEC-2020-0071}{RUSTSEC-2021-0139} & ansi_term & Unmaintained \ \hline

\end{tabular}

\end{center}

UNSAFE RUST CODE DETECTION

Description

Halborn used automated security scanners to assist with the detection of well-known security issues and vulnerabilities. Among the tools used was cargo-geiger, a security tool that lists statistics related to the usage of unsafe Rust code in a core Rust codebase and all its dependencies.

Results

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.

1. Introduction
2. Audit summary
3. Test approach & methodology
4. Scope
5. Risk methodology
6. Scope
7. Assessment summary & findings overview
8. Findings & Tech Details