Prepared by:
HALBORN
Last Updated 04/26/2024
Date of Engagement by: November 28th, 2022 - December 16th, 2022
0% of all REPORTED Findings have been addressed
All findings
1
Critical
0
High
0
Medium
0
Low
0
Informational
1
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.
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.
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)
Code repositories:
Project Name
Repository: Solana Contracts
Commit ID: d9fba17ee028db017af601dccf33e82c48a8b251
Programs in scope:
Debride (programs/debridge)
Debride Settings (programs/settings)
Debride (programs/debridge)
Debride Settings (programs/settings)
Out-of-scope:
third-party libraries and dependencies
financial-related attacks
Critical
0
High
0
Medium
0
Low
0
Informational
1
Impact x Likelihood
HAL-01
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| FEES CAN NEGATE SEND AMOUNT | Informational | - |
// Informational
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.
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();
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.
\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}
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.
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.
// Download the full report
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed