Skip to content

Latest commit

 

History

History
67 lines (43 loc) · 3.17 KB

065.md

File metadata and controls

67 lines (43 loc) · 3.17 KB

Muscular Ceramic Dragonfly

High

Incorrect decimal handling in getMinAmountReceived

Summary

The use of 1e8 as a constant in the getMinAmountReceived function will cause incorrect exchange calculations as an attacker can manipulate token trades based on differing decimal representations.

Root Cause

In getMinAmountReceived function, the use of a hardcoded constant for calculations does not account for the varying decimal places of the input and output tokens.

https://github.com/sherlock-audit/2024-11-oku/blob/main/oku-custom-order-types/contracts/automatedTrigger/AutomationMaster.sol#L100-L120

Internal pre-conditions

No response

External pre-conditions

No response

Attack Path

  1. The attacker identifies two specific tokens, TokenA (which has 6 decimal places) and TokenB (which has 18 decimal places), that will allow them to exploit the fixed decimal handling in the exchange.
  2. The attacker actively monitors the mempool for incoming transactions from users who are attempting to trade these tokens. This is typically done using tools that track pending transactions.
  3. Upon identifying a user transaction to exchange TokenA for TokenB, the attacker prepares to call the getMinAmountReceived function with their own parameters. They specify the amount of TokenA they wish to trade, knowing that the fixed constant of 1e8 will lead to an erroneous calculation of the expected amount of TokenB.
  4. The attacker then submits their transaction with a higher gas price to ensure it gets processed before the user's transaction. This allows the attacker to execute their trade first, thus acquiring a larger amount of TokenB than they would normally be entitled to due to the decimal mismatch.
  5. When the attacker calls getMinAmountReceived, the function uses the hardcoded constant of 1e8 for calculations, which does not consider the differing decimal representations of TokenA and TokenB. This results in the attacker receiving an inflated amount of TokenB.
  6. As a result of the attacker’s manipulation, the user receives significantly less TokenB than they anticipated when their transaction is finally processed. The user’s trade is executed after the attacker’s, leading to financial losses due to the unfavorable exchange rate.

Impact

No response

PoC

// Test for vulnerability  
contract TestVulnerability {  
    VulnerableExchange exchange;  
  
    function setUp() public {  
        exchange = new VulnerableExchange();  
    }  
  
    function testIncorrectMinAmountReceived() public {  
        IERC20 tokenIn = IERC20(address(1)); // Token with 6 decimals  
        IERC20 tokenOut = IERC20(address(2)); // Token with 18 decimals  
  
        uint256 amountIn = 1000; // Input amount  
        uint96 slippageBips = 50; // Slippage  
  
        // Calling the function with differing decimal tokens  
        uint256 minAmount = exchange.getMinAmountReceived(amountIn, tokenIn, tokenOut, slippageBips);  
          
        // Expect minAmount to be incorrect due to fixed decimal handling  
        assert(minAmount != expectedValue); // expectedValue should be calculated considering actual decimals  
    }  
}

Mitigation

No response