Uneven Gingham Locust - Attacker can DoS WooFi deployment

[sherlock-admin3]

Uneven Gingham Locust

Medium

Attacker can DoS WooFi deployment

Summary

Anyone can create the WooConfig account by calling the create_config function immediately after deployment. Any given WooFi program can only have one WooConfig state account and the caller of the create_config becomes the authority for the WooConfig hence controls all admin related functions of the WooFi program.

When an attacker calls the create_config function before the protocol team, the authority can be set to attaker controlled address making the deployment unusable.

Root Cause

The create_config function should check that an admin called the function by comparing against an hardcoded address in the program. The function only ensures that an authority signed the instruction, there are no checks on the address of authority:

https://github.com/sherlock-audit/2024-08-woofi-solana-deployment/blob/main/WOOFi_Solana/programs/woofi/src/instructions/admin/create_config.rs#L7-L9

https://github.com/sherlock-audit/2024-08-woofi-solana-deployment/blob/main/WOOFi_Solana/programs/woofi/src/instructions/admin/create_config.rs#L24-L25

Because deployments work differently on Solana, there is no constructor for the program hence the owner addresses cannot be set like in Ethereum. The initializer address must be hard-coded.

Internal pre-conditions

No response

External pre-conditions

No response

Attack Path

1. The WooFi team deploys the program
2. Eve, an attacker, calls the create_config function.

Impact

Attacker DoSes the deployment

PoC

No response

Mitigation

Hardcode an initializer address and ensure the initializer is signer for the create_config call,

[toprince]

Not valid, Config cannot created twice. reInit is assured by Anchor. you can have a test case to see this.