#37382 [SC-Insight] Inconsistent Collateral Ratio Checks in Stability Pool Withdrawals Lead to Fund-Locking DoS
Submitted on Dec 3rd 2024 at 16:14:10 UTC by @InquisitorScythe for IOP | Fluid Protocol
Report ID: #37382
Report Type: Smart Contract
Report severity: Insight
Target: https://github.com/Hydrogen-Labs/fluid-protocol/tree/main/contracts/stability-pool-contract/src/main.sw
Impacts:
Permanent freezing of funds
Permanent freezing of unclaimed yield
Description
Brief/Intro
In the withdraw_from_stability_pool
function from stability-pool-contract/src/main.sw
, there is an initial check called require_no_undercollateralized_troves
. Unfortunately, this check condition is inappropriate, allowing attackers to prevent legitimate withdrawal operations through front-running at any time. As a result, users' USDF and generated rewards remain locked in the stability pool and cannot be withdrawn.
Vulnerability Details
A critical vulnerability exists in the stability pool contract where users' ability to withdraw their USDF funds can be maliciously blocked through a front-running attack. This is caused by an inconsistency between collateral ratio checks in different contract functions.
The vulnerability stems from the withdraw_from_stability_pool
function's implementation, specifically in its require_no_undercollateralized_troves
check:
The key issue lies in the inequality operator (>) used to compare the Individual Collateral Ratio (ICR) with the Minimum Collateral Ratio (MCR). However, the open_trove function uses a different comparison:
This inconsistency creates an exploitable condition:
Users can legitimately open or adjust troves with exactly MCR (ICR = MCR)
The stability pool withdrawal function will revert if any trove has ICR ≤ MCR An attacker can exploit this by:
Monitoring the mempool for stability pool withdrawal transactions
Front-running these transactions by opening a trove with ICR = MCR
This causes the victim's withdrawal transaction to fail due to the strict inequality check As a result, attackers can effectively prevent specific users from withdrawing their USDF and accumulated gains from the stability pool, creating a denial-of-service condition for legitimate withdrawals. It is possible to lock specific users' fund in the pool as long as possible with little cause.
Possible Fix
Relaxation of withdrawal restrictions, allow user withdraw their fund even when undercollateralized troves exists.
Impact Details
The vulnerability creates a severe denial-of-service condition that directly impacts both users' funds and the protocol's stability. The impact can be broken down into several critical areas:
Direct Financial Impact
Users' USDF deposits and earned collateral rewards become inaccessible in the Stability Pool
Attackers can selectively target and lock specific users' funds indefinitely
Loss of potential earnings from FPT token distributions and collateral rewards
The affected amounts could be significant, as the Stability Pool typically holds substantial deposits
Protocol Stability Risks
Liquidity Impairment:
Reduced effectiveness of the Stability Pool as the first line of defense for liquidations
Decreased Total Collateral Ratio (TCR) protection capability
Potential cascading effect on the protocol's ability to maintain stable operations
Systemic Risks:
Loss of user confidence leading to reduced deposits in the Stability Pool
Increased vulnerability to bank run scenarios
Compromised liquidation mechanisms if Stability Pool liquidity becomes insufficient
Long-term Protocol Damage
Reputational damage to Fluid Protocol
Reduced user trust leading to decreased protocol adoption
Potential exodus of existing users due to fund accessibility concerns
Negative impact on protocol's competitive position in the DeFi ecosystem
The severity is heightened because:
The attack can be executed at any time
It requires very low cost to execute
The impact is persistent until protocol code is updated
There's no immediate workaround for affected users
This vulnerability falls within the program's scope as it directly impacts fund accessibility and protocol stability, warranting a critical-severity classification.
References
None
Proof of Concept
Proof of Concept
Add following test in contracts/stability-pool-contract/tests/functions/failure.rs