Glamorous Violet Chameleon - Attacker can control Oracles and Pools by front-running their creation

[sherlock-admin3]

Glamorous Violet Chameleon

High

Attacker can control Oracles and Pools by front-running their creation

Summary

Anyone can create Oracles and since the signer is not included in the Oracle's seeds, Oracles that use the same base token and feeds will be the same across different signers.

An attacker can front-run Oracle creation with them as the authority for any token pair like SOL/USDT. Once the attacker controls the Oracle, they can also create its accompanying SOL/USDT Pool. This gives the attacker control over the prices of swaps and steal from users.

Root Cause

In create_wooracle:51-57, the signer is not included in the seeds. This leads to only 1 Pool per base token (it should be per token pair and this is covered in a separate report) and vulnerability to front-running.

  #[account(
      init,
      payer = admin,
      space = 8 + Wooracle::INIT_SPACE,
      seeds = [
          WOORACLE_SEED.as_bytes(),
          wooconfig.key().as_ref(),
          token_mint.key().as_ref(),
          feed_account.key().as_ref(),
          price_update.key().as_ref()
          ],
      bump,
  )]
  wooracle: Account<'info, Wooracle>,

Internal pre-conditions

None

External pre-conditions

None

Attack Path

1. An attacker front-runs the creation of an Oracle of the target pair SOL/USDC by invoking create_wooracle() making sure to use the official Pyth price feed and price update accounts for SOL/USD.
2. Now that the attacker has created the SOL/USDC Oracle, no other user can create an Oracle using the same base token, price feed, and price update accounts. The attacker controls the "canonical" Oracle for SOL/USDC.
3. The attacker creates a pool paired to their SOL/USDC Oracle which sets them as the authority.
4. The attacker now controls the price, spread, coefficient, and other parameters of the Pool and Oracle of SOL/USDC. All swaps involving SOL/USDC will be vulnerable to loss of funds with the attacker manipulating those parameters.

Note that Oracle admins set by the protocol team can also set price, spread, and coefficient. However, the attacker can front-run user swaps when manipulating parameters to steal funds.

The attacker will lose all revenue in the Pools the attacker controls. Even when the attacker does not steal from users, they steal revenue meant for the protocol.

Impact

The Protocol will lose all revenue in the Pools stolen by the attacker. Users can experience a permanent loss of funds when doing swaps in the attacker-controlled pools. Note that the attacker can control all supported pools/oracles.

PoC

No response

Mitigation

Consider adding the signer to the seeds of the Oracle. That way, different signers will create different Oracles.

[toprince]

different signer can create his pool. But cannot swap with correct pool. Impact is low.