033.md

Glamorous Tweed Albatross

Medium

Overflow and Misconfiguration Risks in feeBips and Slippage Parameters

Summary

The feeBips, takeProfitSlippage, and stopSlippage parameters are constrained to a maximum of 10,000 (representing 100%). However, there is no validation for minimum bounds, which allows for configurations that may lead to:

• Zero values causing unexpected behavior.
• High values (near 10,000) resulting in impractical fees or slippage rates, causing unfavorable trade conditions. https://github.com/sherlock-audit/2024-11-oku/blob/main/oku-custom-order-types/contracts/automatedTrigger/Bracket.sol#L466-L471

Root Cause

The validation logic ensures these parameters do not exceed 10,000 but fails to: 1- Check for values greater than zero. 2- Enforce practical bounds below 100%.

Internal pre-conditions

1- Fee and Slippage Parameter Inputs

• Parameters are directly provided by users or external systems during order creation or modification.

2- Fee and Slippage Logic:

• Calculations rely on feeBips and slippage parameters, making extreme values (close to or at 10,000) potentially disruptive.

External pre-conditions

1- User Input Errors:

• Users might unintentionally set impractical values for slippage or fees.

2-Exploit Potential:

• Attackers might intentionally set maximum allowable values to cause edge-case scenarios, such as 100% fees or excessive slippage.

Attack Path

Step 1 Malicious actor sets the following parameters:

• feeBips = 10,000 (100% fee).
• takeProfitSlippage = 10,000 (100% slippage).
• stopSlippage = 10,000 (100% slippage).

Step 2 The attacker creates an order using these values:

createOrder(
    swapPayload,
    2000,   // takeProfit
    1800,   // stopPrice
    100,    // amountIn
    tokenIn,
    tokenOut,
    attacker,
    10000,  // feeBips (100% fee)
    10000,  // takeProfitSlippage (100%)
    10000   // stopSlippage (100%)
);

Step 3 During execution:

• Fees consume the entire output, resulting in no net gain for the user.
• Slippage allows trades at significantly unfavorable rates, potentially draining user funds.

Step 4 Impact on Platform:

• Orders fail to provide meaningful outcomes for users.
• The platform's reputation suffers as users perceive it as unreliable or predatory.

Impact

1- Financial Loss:

• Users may lose all funds due to excessive fees or unfavorable slippage configurations.

2- Platform Integrity:

• Excessive slippage or fees may lead to failed trades, undermining user confidence.

3- Systemic Risk:

• High slippage or fees in multiple orders could create operational bottlenecks or failures.

PoC

Create Malicious Order: Call the createOrder function with:

createOrder(
    swapPayload,
    2000,   // takeProfit
    1800,   // stopPrice
    100,    // amountIn
    tokenIn,
    tokenOut,
    recipient,
    10000,  // feeBips (100% fee)
    10000,  // takeProfitSlippage (100%)
    10000   // stopSlippage (100%)
);

Execution: Observe the output:

• Fees: Entire output is consumed by fees, leaving zero tokens for the recipient.
• Slippage: Trades execute at extreme rates, depleting funds.

Impact: The order results in a complete loss for the user.

Mitigation

Set Practical Limits: Define acceptable ranges for feeBips, takeProfitSlippage, and stopSlippage:

uint16 constant MAX_FEE_BIPS = 500;  // 5%
uint16 constant MAX_SLIPPAGE = 500; // 5%
uint16 constant MIN_FEE_BIPS = 10;  // 0.1%
uint16 constant MIN_SLIPPAGE = 10;  // 0.1%

Enforce Limits During Validation:

require(
    stopSlippage >= MIN_SLIPPAGE && stopSlippage <= MAX_SLIPPAGE &&
    takeProfitSlippage >= MIN_SLIPPAGE && takeProfitSlippage <= MAX_SLIPPAGE &&
    feeBips >= MIN_FEE_BIPS && feeBips <= MAX_FEE_BIPS,
    "Invalid BIPS values"
);

Provide Default Values: Assign reasonable defaults if users fail to specify parameters.

Enhance Error Messaging: Provide detailed feedback for invalid inputs:

require(
    stopSlippage >= MIN_SLIPPAGE,
    "Stop slippage too low"
);
require(
    stopSlippage <= MAX_SLIPPAGE,
    "Stop slippage too high"
);