medium

Exploiting Precision Loss in StableModule for Unfair Withdrawals Which Results to Manipulation of Input Value

Summary

An attacker can manipulate input values in StableModule to exploit the loss of precision in fee and withdrawal calculations. By providing specific withdrawal amounts and other inputs, the attacker can cause the contract to calculate higher-than-expected withdrawal amounts or lower-than-expected fees. This manipulation allows the attacker to gain an unfair financial advantage and extract more funds from the contract over time. Proper use of fixed-point arithmetic and rigorous testing can mitigate this vulnerability.

Vulnerability Detail

The StableModule contract contains multiple functions that perform calculations involving fees, collateral, and withdrawals. The core of the vulnerability lies in the potential loss of precision during calculations, which can be exploited by an attacker.

Calculations: Functions like executeWithdraw() and stableWithdrawQuote() use a series of arithmetic operations including multiplication and division to calculate the withdrawal amount (_amountOut) and fees (_withdrawFee). These operations are vulnerable to precision loss, especially when division is performed before multiplication.
Exploit Scenario: An attacker can carefully craft input values (such as withdrawal amounts) that lead to precision errors during the arithmetic operations in the contract. For instance, the attacker may use values that cause rounding errors or discrepancies in the final calculated amounts.

Impact

Loss of Precision: Performing a multiplication on the result of a division can lead to loss of precision in the final outcome. This is due to the fact that intermediate results may be truncated or rounded during division, which can then affect subsequent multiplications.
Incorrect Calculations: The imprecisions introduced due to performing operations in this manner can lead to incorrect calculations of various metrics such as fees, withdrawals, or collateral balances. This can negatively impact users and their transactions within the contract.
Financial Discrepancies: Incorrect calculations may result in financial discrepancies such as overcharging fees or incorrectly valuing collateral and balances. This can lead to unfair outcomes for users.
Potential Exploitation: Inaccuracies and imprecisions may open the door to exploitation by malicious actors who could take advantage of the discrepancies in the contract's operations.

Code Snippet

https://github.com/sherlock-audit/2024-03-flat-money-fix-review-contest/blob/main/flatcoin-v1/src/StableModule.sol#L93

Proof of Concept

Deploy the StableModule contract and initialize it with appropriate parameters.
Set up accounts: We'll need a victim's account and an attacker's account.
Mint some LP tokens to the attacker's account for testing purposes.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.20;

import "./StableModule.sol"; 
import "libraries/FlatcoinStructs.sol"; 

contract StableModuleExploit {
    StableModule stableModule;
    address attacker;
    address victim;

    constructor(address _stableModule, address _attacker, address _victim) {
        stableModule = StableModule(_stableModule);
        attacker = _attacker;
        victim = _victim;
    }

    function exploit() public {
        require(msg.sender == attacker, "Only attacker can run this exploit");

        // Step 1: Prepare the withdrawal request
        uint256 withdrawAmount = 1_000_000_000; // Set a specific withdraw amount
        uint64 executableAtTime = uint64(block.timestamp); // Immediate execution
        FlatcoinStructs.AnnouncedStableWithdraw memory announcedWithdraw = FlatcoinStructs.AnnouncedStableWithdraw({
            withdrawAmount: withdrawAmount
        });

        // Step 2: Execute the withdrawal as the attacker
        stableModule.executeWithdraw(attacker, executableAtTime, announcedWithdraw);

        // Step 3: Observe the outcome
        // Check the attacker's balance to see if they received more funds than expected
        uint256 attackerBalance = stableModule.balanceOf(attacker);
        // Log the attacker's balance to observe the outcome
        emit ExploitOutcome(attackerBalance);
    }

    event ExploitOutcome(uint256 attackerBalance);
}

Tool used

Slither Manual Review

Recommendation

Consider adjusting the code to prioritize multiplying before dividing where possible, or using fixed-point arithmetic libraries that provide more precise calculations. By addressing these potential issues, the stability and accuracy of the contract's operations can be improved.

sherlock-audit / 2024-03-flat-money-fix-review-contest-judging

BZ - Exploiting Precision Loss in StableModule for Unfair Withdrawals Which Results to Manipulation of Input Value #24