However, the current enable_pool_579_D_A658 function implementation allows senders with the authorised_enablers role to not only enable the pool but also disable it.
Impact
Because liquidity cannot be removed when the pool is locked, allowing senders with the authorised_enablers role to disable pools is a critical access control issue. This could allow a malicious sender to lock the liquidity of all users until the seawater admin restricts the malicious enabler.
Proof of Concept
The authorized enabler calls the enable_pool_579_D_A658 function with a pool address and enabled parameter set to false (see comments):
Add proper checks to prevent authorized enablers from disabling pools. For instance, add the following check at the beginning of the enable_pool_579_D_A658 function:
Lines of code
https://github.com/code-423n4/2024-08-superposition/blob/4528c9d2dbe1550d2660dac903a8246076044905/pkg/seawater/src/lib.rs#L120-L121
Vulnerability details
According to the documentation, the
authorised_enablers
should only be allowed to create new pools and enable them:lib.rs#L120-L121
However, the current
enable_pool_579_D_A658
function implementation allows senders with theauthorised_enablers
role to not only enable the pool but also disable it.Impact
Because liquidity cannot be removed when the pool is locked, allowing senders with the
authorised_enablers
role to disable pools is a critical access control issue. This could allow a malicious sender to lock the liquidity of all users until the seawater admin restricts the malicious enabler.Proof of Concept
The authorized enabler calls the
enable_pool_579_D_A658
function with a pool address andenabled
parameter set tofalse
(see comments):lib.rs#L1169-L1187
Tools Used
Manual review.
Recommended Mitigation Steps
Add proper checks to prevent authorized enablers from disabling pools. For instance, add the following check at the beginning of the
enable_pool_579_D_A658
function:Assessed type
Access Control