zigtur - Any user will gain authority on RebateManager

[sherlock-admin4]

zigtur

Medium

Any user will gain authority on RebateManager

Summary

A create_rebate_manager transaction from the protocol can be front-run by anyone to gain authority over a RebateManager.

Root Cause

• In create_rebate_manager.rs#L11-L12, the authority signer is not checked to ensure it is a trusted address.
• In create_rebate_manager.rs#L14-L23, the initialization of a RebateManager is based on "first come, first served"
• In create_rebate_manager.rs#L14-L23, the RebaseManager PDA is derived from the quote_token_mint public key. We know that project will support USDT, USDC and SOL so these parameters are known.

Internal pre-conditions

•  RebateManager associated to the given token must not have been initialized

External pre-conditions

No response

Attack Path

1. User calls create_rebase_instruction before the project, with a token address that the project aims to support (USDT, USDC, SOL).

Impact

• User gain authority over the token's rebate manager (for example USDT)
• Protocol will never be able to gain authority over this token's rebate manager

PoC

No response

Mitigation

The program should set an access control check on the create_rebase_manager instruction to ensure that the signer (authority) is trusted.

[toprince]

Any one can deploy a contract and gain owner authority. Like anyone can deploy a new coin called itself USDT... You can already create a rebate manager now. But we will not use that. So not see pre create is a issue...

[sherlock-admin2]

The protocol team fixed this issue in the following PRs/commits: https://github.com/woonetwork/WOOFi_Solana/pull/45

[gjaldon]

This change fixes the issue by including the signer's key in the seeds for the rebate manager. Each signer will now create a different rebate manager and attackers can no longer control the single global rebate manager.