Attacker will initialize WooOracle before the project

Summary

The missing access control check in create_wooracle instruction allows an attacker to initialize the wooracle, to gain authority over it.

Root Cause

In create_wooracle.rs#L62, there is no access control to ensure that the admin is trusted (is part of the wooconfig).
In create_wooracle.rs#L47-L59, the Wooracle PDA account can be initialized only once with the correct seeds.

Internal pre-conditions

The Wooracle PDA account with the correct seeds is not initialized

External pre-conditions

No response

Attack Path

Attacker executes create_wooracle instruction with the correct parameters.

Impact

Attacker gains authority over the wooracle at create_wooracle.rs#L86. This allows him to:

initialize the corresponding pool, and become authority over it to drain funds (through incase_token_got_stuck).
manipulate the oracle (through the set_woo_price instruction for example)
set an unexpected quote_feed_account unrelated to quote_token_mint

Moreover, the protocol is not able to regain authority on this oracle and the derived pool.

PoC

No response

Mitigation

Add a constraint on admin to ensure that it is trusted. This can be done by checking that the admin is part of the authority like this:

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

Note: External WooConfig accounts that are not owned by the current program can be used to bypass this check. However, as the wooconfig key is used to in the PDA seeds of the wooracle, it does not have impact on the protocol.