Skip to content

Latest commit

 

History

History
133 lines (93 loc) · 3.47 KB

034.md

File metadata and controls

133 lines (93 loc) · 3.47 KB

Glamorous Tweed Albatross

High

Risk of Denial of Service Due to Lack of Pending Order Management on _createrOrder

Summary

The pendingOrderIds array enforces a maximum limit on the number of pending orders using the condition: https://github.com/sherlock-audit/2024-11-oku/blob/main/oku-custom-order-types/contracts/automatedTrigger/Bracket.sol#L462-L465 However, the contract lacks a mechanism to handle scenarios where the maximum is reached, potentially causing a Denial of Service (DoS) by preventing users from creating new orders.

Root Cause

The absence of mechanisms to manage pendingOrderIds, such as automatic expiration, cancellation, or capacity adjustment, leads to a rigid system where hitting the maximum capacity halts further order creation.

Internal pre-conditions

1- Max Capacity Defined: MASTER.maxPendingOrders() imposes a hard limit on pending orders.

2- Lack of Management: No mechanisms exist to handle stale or completed orders in pendingOrderIds.

External pre-conditions

1- High Usage: Multiple users creating orders in quick succession could exhaust the pending order capacity.

2- Stale Orders: Orders that are no longer actionable remain in the system, contributing to capacity exhaustion.

Attack Path

Step 1

  • A malicious user repeatedly creates orders until pendingOrderIds reaches the maximum limit.

Step 2 At maximum capacity:

  • Legitimate users attempting to create orders encounter the Max Order Count Reached error.
  • The platform becomes unusable for order creation.

Step 3 Impact:

  • Denial of Service for all users.
  • Potential disruption to platform operations.

Impact

Denial of Service: Legitimate users are unable to create new orders, causing frustration and loss of trust.

Operational Risk: The platform may experience disruptions if users cannot interact with the system effectively.

PoC

1- Setup: Deploy the Bracket.sol contract to a testnet with MASTER.maxPendingOrders() set to a low value (e.g., 3).

2- Create Orders: Call createOrder repeatedly until pendingOrderIds reaches the maximum capacity:

createOrder(
    swapPayload,
    takeProfit,
    stopPrice,
    amountIn,
    tokenIn,
    tokenOut,
    recipient,
    feeBips,
    takeProfitSlippage,
    stopSlippage
);

3- Attempt Additional Order: Observe the Max Order Count Reached error.

4- Impact: No further orders can be created.

Mitigation

Proposed Fix

Order Expiration: Introduce a time-based expiration mechanism to remove stale orders:

struct Order {
    uint256 timestamp;
    // Other parameters...
}

function expireOldOrders() internal {
    for (uint96 i = 0; i < pendingOrderIds.length; i++) {
        if (block.timestamp - orders[pendingOrderIds[i]].timestamp > MAX_ORDER_AGE) {
            _cancelOrder(orders[pendingOrderIds[i]]);
        }
    }
}

Order Removal: Allow users or administrators to cancel orders manually:

function removeOrder(uint96 orderId) external {
    require(msg.sender == orders[orderId].recipient, "Not order owner");
    _cancelOrder(orders[orderId]);
}

Dynamic Limits: Adjust maxPendingOrders dynamically based on system load or user activity:

uint256 dynamicMax = baseMax + (loadFactor * multiplier);

Clear Completed Orders: Ensure completed orders are removed from pendingOrderIds during the performUpkeep process:

pendingOrderIds = ArrayMutation.removeFromArray(data.pendingOrderIdx, pendingOrderIds);