zigtur - Attacker will create pool and oracle for token that are planned to be supported in the future

[sherlock-admin2]

zigtur

High

Attacker will create pool and oracle for token that are planned to be supported in the future

Summary

Any user can initialize the oracle attached to a token (reported in another issue). Then, with this oracle, the user can initiliaze the pool and gain authority over it. Once the pool is initialized, project can't reinitialize it and will not be able to retrieve authority over it.

Root Cause

• In create_pool.rs#L9, there is no constraint on wooconfig to ensure it is the correct PDA.
• In create_pool.rs#L14, there is no constraint to ensure that the admin is the one configured in the wooconfig.

Internal pre-conditions

No response

External pre-conditions

No response

Attack Path

1. Project initialize USDT and SOL pools
2. Attacker initializes USDC pool
3. Attacker is USDC pool authority, so it can withdraw value from other pools through swapping as he control his pool's configuration.

Impact

The attacker controls the whole pool configuration and can impact other pools through swapping.

PoC

No response

Mitigation

Pool creation should only be allowed to the authorities set in wooconfig.

#[derive(Accounts)]
pub struct CreatePool<'info> {
    #[account(
        seeds = [
          WOOCONFIG_SEED.as_bytes(),
        ],
        bump)]
    pub wooconfig: Box<Account<'info, WooConfig>>,
    pub token_mint: Account<'info, Mint>,
    pub quote_token_mint: Account<'info, Mint>,

    #[account(mut,
        constraint =
            wooracle.authority == authority.key() ||
            wooconfig.wooracle_admin_authority.contains(authority.key)
    )]
    pub authority: Signer<'info>,

[toprince]

valid. but low impact. same with other.