Insufficient Access Control on OAppConfig Initialization
Summary
The vulnerability allows any user to initialize the oapp_config without proper access control. Since the InitOApp function does not verify that only authorized entities can create or modify the OAppConfig account, an attacker could maliciously initialize or reinitialize the account, potentially overriding critical parameters.
The root cause of this vulnerability is the absence of a check to ensure that only authorized users can invoke the InitOApp instruction. The program allows any signer with enough funds to initialize the oapp_config and lz_receive_typesaccounts without verifying whether the signer is allowed to perform this action.
Internal pre-conditions
The InitOApp instruction lacks a constraint to restrict its execution to an authorized administrator or a specified public key.
The payer can initialize the oapp_config account without proving ownership or administrative rights.
No validation is performed on the admin parameter passed to the instruction.
External pre-conditions
Any user with sufficient funds to cover the rent and fees for account initialization can call the InitOApp function.
No prior account has been initialized for oapp_config and lz_receive_types.
Attack Path
Attacker invokes the InitOApp instruction and provides valid parameters.
The program creates or reinitializes the oapp_config and lz_receive_types accounts based on the attacker's input.
The attacker gains control over important parameters like usdc_hash, usdc_mint, and the admin public key, potentially allowing them to override these values and control future behavior of the OApp.
Impact
Parameter Override: An attacker could maliciously set or reset important values (e.g., USDC mint address, admin public key), leading to a loss of control over the program.
Denial of Service: The attacker could reinitialize the oapp_config with invalid values, disrupting the proper functioning of the OApp.
Potential Financial Exploits: If financial parameters such as usdc_mint are altered, the attacker could exploit the system to divert funds or disrupt token flows.
PoC
Attacker generates valid parameters for InitOApp (e.g., an arbitrary admin public key, a new USDC mint).
The attacker sends a transaction to the program, calling the InitOApp instruction and paying for account initialization.
The oapp_config is initialized using the attacker's inputs, allowing them to control the OApp behavior.
The attacker submits the following transaction to initialize the oapp_config and lz_receive_types:
let ix = InitOApp {
payer: attacker_pubkey,
system_program: system_program_id,
oapp_config: oapp_config_pda,
lz_receive_types: lz_receive_types_pda,
};
// Set admin and other params
let params = InitOAppParams {
admin: attacker_pubkey,
endpoint_program: Some(attacker_program_id),
usdc_hash: [0; 32],
usdc_mint: attacker_usdc_mint,
};
// Call the instruction
invoke(&ix, ¶ms);
The attacker now controls the oapp_config and lz_receive_types accounts.
Mitigation
Add Authorization Check:
Ensure that only authorized users (e.g., a pre-specified admin) can initialize the oapp_config account.
#[account(
init,
payer = payer,
space = 8 + OAppConfig::INIT_SPACE,
seeds = [OAPP_SEED],
bump,
has_one = admin @OAppError::Unauthorized // Only the admin can initialize
)]
pub oapp_config: Account<'info, OAppConfig>,
Restrict Initialization to Once:
Use a state flag to prevent the re-initialization of oapp_config after the first setup.
if oapp_config.is_initialized {
return Err(ProgramError::AccountAlreadyInitialized.into());
}
Use Program-Specific Seeds:
Use a more secure and complex seed derivation method to ensure only authorized entities can derive the oapp_config PDA.
Broad Pecan Pheasant
High
Insufficient Access Control on OAppConfig Initialization
Summary
The vulnerability allows any user to initialize the oapp_config without proper access control. Since the InitOApp function does not verify that only authorized entities can create or modify the OAppConfig account, an attacker could maliciously initialize or reinitialize the account, potentially overriding critical parameters.
Root Cause
https://github.com/sherlock-audit/2024-09-orderly-network-solana-contract/blob/main/solana-vault/packages/solana/contracts/programs/solana-vault/src/instructions/oapp_instr/init_oapp.rs#L8-L28
The root cause of this vulnerability is the absence of a check to ensure that only authorized users can invoke the InitOApp instruction. The program allows any signer with enough funds to initialize the
oapp_config
andlz_receive_types
accounts without verifying whether the signer is allowed to perform this action.Internal pre-conditions
External pre-conditions
Attack Path
Impact
PoC
The attacker now controls the oapp_config and lz_receive_types accounts.
Mitigation
Add Authorization Check: Ensure that only authorized users (e.g., a pre-specified admin) can initialize the oapp_config account.