Broad Pecan Pheasant - Unauthorized Deposit into Another User's Vault

[sherlock-admin4]

Broad Pecan Pheasant

Medium

Unauthorized Deposit into Another User's Vault

Summary

https://github.com/sherlock-audit/2024-09-orderly-network-solana-contract/blob/main/solana-vault/packages/solana/contracts/programs/solana-vault/src/instructions/vault_instr/deposit.rs#L33-L38

The vulnerability allows any user to deposit tokens into another user's vault without proper ownership verification. This occurs due to the lack of user-specific checks when depositing tokens into the shared vault authority. The program does not ensure that the vault is uniquely tied to the user making the deposit, potentially leading to fund mismanagement or exploitation.

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/vault_instr/deposit.rs#L33-L38

The root cause of this vulnerability lies in the absence of ownership validation when interacting with the vault_authority account. The vault_authority is derived using a shared seed without ensuring that each vault is tied to a specific user, allowing unauthorized users to deposit into vaults they do not own.

Internal pre-conditions

1. The program uses a common seed (VAULT_AUTHORITY_SEED) to derive the vault_authority without associating it directly with the user's public key.
2. The vault_authority PDA can be accessed by any user, with no explicit owner checks to restrict deposits.
3. The program lacks a verification mechanism to ensure the depositor is the owner of the vault.

External pre-conditions

1. A malicious user must know or guess the process of seed derivation for vault_authority. 2.The attacker must have access to the deposit mechanism and valid parameters (e.g., token information, account IDs). 3.No specific authorization check is enforced before allowing token deposits into a vault.

Attack Path

1. Alice creates a vault using the vault_authority derived from the shared VAULT_AUTHORITY_SEED.
2. Bob, another user, interacts with the same deposit function, targeting Alice's vault_authority.
3. Since the program does not check whether Bob is the owner of the vault, Bob successfully deposits tokens into Alice’s vault, without her consent or knowledge.

Impact

1. Fund Mismanagement: Unauthorized users can deposit tokens into a vault owned by another user, leading to possible confusion or misappropriation of funds.
2. Potential Exploitation: Malicious users can manipulate vaults belonging to others, potentially leading to further financial exploits, depending on how the vault tokens are utilized.

PoC

1. Alice initiates a vault using the shared VAULT_AUTHORITY_SEED to derive her vault_authority.
2. Bob calls the deposit function:
   • Uses Alice's vault_authority (since the seed derivation process is the same for everyone).
   • Bob successfully deposits his tokens into Alice’s vault.
3. Bob’s deposit is accepted without verifying that the vault belongs to him.

Use Unique PDAs for Each User's Vault: Derive the vault_authority PDA using a unique seed that includes the user’s public key, ensuring that each user has a unique vault authority.

    #[account(
        mut,
        seeds = [VAULT_AUTHORITY_SEED, user.key().as_ref()],
        bump = vault_authority.bump,
    )]
    pub vault_authority: Box<Account<'info, VaultAuthority>>,

Mitigation

Use Unique PDAs for Each User's Vault: Derive the vault_authority PDA using a unique seed that includes the user’s public key, ensuring that each user has a unique vault authority.

seeds = [VAULT_AUTHORITY_SEED, user.key().as_ref()],