Closed c4-bot-9 closed 5 months ago
0xRobocop marked the issue as sufficient quality report
0xRobocop marked the issue as primary issue
Related to #188
enthusiastmartin (sponsor) disputed
This is incorrect.
add_token is designed to add new token to the pool, with any liquidity volume. It does not need to respect the chosen weight cap for that asset.
While add_token
does not check the weight caps, this function is permissioned. This means that AuthorityOrigin
does not need to respect the defined soft limits, which is a valid design decision. Therefore downgrading to QA.
OpenCoreCH changed the severity to QA (Quality Assurance)
OpenCoreCH marked the issue as grade-b
Lines of code
https://github.com/code-423n4/2024-02-hydradx/blob/main/HydraDX-node/pallets/omnipool/src/lib.rs#L483
Vulnerability details
Impact
By front-running the
add_token()
with a direct transfer to the pool account, an attacker can break the weight cap restriction.Proof of Concept
To defend against some liquidity attacks, every asset in the omnipool has a weight cap that can't be broken when liquidities are adding to the pool. However, when the authorities add tokens that provide the initiative liquidity, we don't check whether the weight cap is broken. This is correct and fine for the first added token since there are no other tokens in the pool, but for subsequent tokens, this can lead to:
add_token
with initial liquidity.transfer
with higher tip fees to front-running and transfer tokens directly to the pool.add_token
, the token pair is created and the weight cap is broken.Tools Used
Manual Review.
Recommended Mitigation Steps
In
add_token
, ifAssets
is not empty (not the first added token), we should make sure the weight cap is not broken just like we do inadd_liquidity
:Assessed type
Context