Skip to content

Latest commit

 

History

History
126 lines (91 loc) · 4.41 KB

031.md

File metadata and controls

126 lines (91 loc) · 4.41 KB

Flaky Merlot Parrot

High

Missing Oracle Validation for tokenOut in _createOrder Enables Invalid Orders and Operational Failures

Summary

The _createOrder function in Bracket.sol fails to validate the existence of an oracle for tokenOut, focusing solely on tokenIn. This critical oversight allows the creation of orders involving tokens without a valid oracle, leading to operational failures, order execution errors, financial loss, and potential systemic exploitation.

Root Cause

The require statement incorrectly validates MASTER.oracles(tokenIn) twice,overlooking the necessary validation of MASTER.oracles(tokenOut). As a result, tokens without a valid oracle can be used in orders, disrupting subsequent contract operations. https://github.com/sherlock-audit/2024-11-oku/blob/main/oku-custom-order-types/contracts/automatedTrigger/Bracket.sol#L455-L461

Internal pre-conditions

Partial Oracle Validation: The function validates only tokenIn for an associated oracle.

Oracle Dependency: The contract relies on MASTER.oracles for pricing data to calculate exchange rates and execute trades.

External pre-conditions

Invalid Tokens: Tokens without an oracle can still be specified as tokenOut in an order.

Order Execution: The platform attempts to execute all valid orders, regardless of tokenOut's oracle status.

Attack Path

Step 1: Attacker observes that tokenOut is not validated during order creation.

Step 2: Attacker creates a malicious order using:

  • A valid tokenIn with an associated oracle.
  • An invalid tokenOut without an associated oracle
 _createOrder(
   2000,           // takeProfit
   1800,           // stopPrice
   100,            // amountIn
   0,              // existingOrderId
   validTokenIn,   // tokenIn with oracle
   invalidTokenOut,// tokenOut without oracle
   recipient,
   10,             // feeBips
   50,             // takeProfitSlippage
   50              // stopSlippage
);

Step 3: The order passes validation and is added to the contract's internal state.

Step 4: During execution, any function requiring tokenOut's oracle (e.g., checkInRange, _getExchangeRate) fails, causing:

  • Contract reversion or execution errors.
  • Platform disruption affecting all users.

Impact

Operational Disruption: Orders with invalid tokenOut oracles fail execution, reverting critical functions like performUpkeep or causing partial contract downtime.

Financial Loss: Users attempting to execute orders with invalid tokenOut encounter failed transactions, incurring unnecessary gas fees or delays.

Market Manipulation: Attackers could use the invalid orders to manipulate platform metrics (e.g., pending orders) or create fake liquidity signals.

Cascading Failures:

  • Repeated execution failures could:
  • Block legitimate orders in shared execution batches.
  • Trigger retries or revert the performUpkeep transaction.

Erosion of Trust: Users lose confidence in the platform due to inconsistent order processing and execution failures.

PoC

1-Deploy the Contract: Deploy the Bracket.sol contract to a public testnet.

2- Simulate Malicious Order Creation: Use a valid token (validTokenIn) and an invalid token (invalidTokenOut without an oracle) to create an order:

_createOrder(
    2000,           // takeProfit
    1800,           // stopPrice
    100,            // amountIn
    0,              // existingOrderId
    validTokenIn,   // tokenIn with oracle
    invalidTokenOut,// tokenOut without oracle
    recipient,
    10,             // feeBips
    50,             // takeProfitSlippage
    50              // stopSlippage
);

3- Observe Successful Creation:

  • The order is created successfully despite tokenOut lacking an oracle.

4- Execute Order:

  • Call performUpkeep or another function that triggers order execution.
  • Observe failure when the contract attempts to fetch the oracle price for tokenOut, leading to transaction reversion.

5- Impact Demonstration: Add multiple malicious orders to simulate cascading failures in batch executions.

Mitigation

Proposed Fix

Correct Oracle Validation: Modify the require statement to validate tokenOut:

require(
    address(MASTER.oracles(tokenIn)) != address(0x0) &&
-   address(MASTER.oracles(tokenIn)) != address(0x0),
+   address(MASTER.oracles(tokenOut)) != address(0x0),
    "Oracle !exist"
);