Skip to content

Latest commit

 

History

History
91 lines (61 loc) · 3.21 KB

043.md

File metadata and controls

91 lines (61 loc) · 3.21 KB

Glamorous Tweed Albatross

Medium

Integer Overflow Risk in applyFee Function Leading to Transaction Failures

Summary

The applyFee function performs arithmetic operations on the amount parameter without explicitly validating its range. Although Solidity 0.8+ has built-in overflow protection, handling unexpected exceptions caused by very large amount values could lead to transaction reverts. This introduces a potential denial-of-service (DoS) risk, especially in scenarios where users or attackers attempt to exploit the function with extreme inputs. File: Bracket.sol https://github.com/sherlock-audit/2024-11-oku/blob/main/oku-custom-order-types/contracts/automatedTrigger/Bracket.sol#L618-L630

Root Cause

Issue Flow

Unvalidated Input: The function does not validate the amount parameter. If amount is too large, the multiplication (amount * (10000 - feeBips)) could exceed the maximum value for uint256.

Overflow Handling: Solidity 0.8+ automatically reverts on overflow, which could halt the contract's execution when unexpected large inputs are provided.

Potential Denial of Service: Attackers could exploit this by submitting abnormally large amount values, causing the function to revert and preventing order processing.

Internal pre-conditions

No response

External pre-conditions

No response

Attack Path

Exploit Scenario

Setup: 1-Bob calls a function that indirectly invokes applyFee with an unreasonably large amount value. 2-The fee percentage (feeBips) is a valid value (e.g., 500 bips or 5%).

Execution: 1- The calculation (amount * (10000 - feeBips)) exceeds the uint256 limit. 2- Solidity’s overflow protection kicks in, causing the transaction to revert.

Outcome:

  • Bob’s transaction fails, even if he intended to execute a legitimate action.
  • If multiple users encounter this issue, it could disrupt the contract's operation.

Impact

Severity: Medium-High

Transaction Reverts: Legitimate users could experience transaction failures if their amount values inadvertently approach the upper limits of uint256.

Denial of Service: Attackers could disrupt the contract’s operation by crafting malicious inputs, leading to a DoS scenario for critical contract functionality.

Loss of User Trust: Repeated failures caused by improperly handled edge cases erode user confidence in the protocol.

PoC

No response

Mitigation

Add explicit input validation to ensure that the amount parameter is within a safe range before performing calculations. Define a reasonable MAX_AMOUNT constant based on the protocol’s requirements.

Fixed Code:

uint256 constant MAX_AMOUNT = type(uint256).max / 10000; // Safe maximum amount for calculations

function applyFee(
    uint256 amount,
    uint16 feeBips
) internal pure returns (uint256 feeAmount, uint256 adjustedAmount) {
    require(amount <= MAX_AMOUNT, "Amount exceeds safe limit");
    require(feeBips <= 10000, "Invalid fee bips"); // Sanity check for bips

    if (feeBips != 0) {
        // Determine adjusted amount and fee amount
        adjustedAmount = (amount * (10000 - feeBips)) / 10000;
        feeAmount = amount - adjustedAmount;
    } else {
        return (0, amount);
    }
}