Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lively Pecan Griffin - USDT Token Approval Deadlock in Automated Order Execution System #870

Open
sherlock-admin3 opened this issue Dec 9, 2024 · 0 comments

Comments

@sherlock-admin3
Copy link
Contributor

Lively Pecan Griffin

Medium

USDT Token Approval Deadlock in Automated Order Execution System

Summary

Critical vulnerability in Oku's automated order system where non-compliant ERC20 tokens can create a permanent deadlock in the execution flow, affecting both Bracket.sol and oracleLess.sol contracts.

Root Cause

function execute(
    address target,
    bytes memory txData,
    uint256 amountIn,
    IERC20 tokenIn,
    IERC20 tokenOut,
    uint16 bips
) internal returns (uint256 swapAmountOut, uint256 tokenInRefund) {
    // Vulnerable single-step approval
    tokenIn.safeApprove(target, amountIn);
    
    // Low-level call execution
    (bool success, bytes memory result) = target.call(txData);
    // ... rest of logic
}

Internal pre-conditions

  1. Active automation system
  2. Residual allowance from previous execution
  3. Integration with DEX routers operational

External pre-conditions

  1. Market liquidity available
  2. Non-standard token implementation (e.g., USDT, USDC)
  3. Router supporting partial fills

Attack Path

// Example Scenario:

// T0: Initial State
initialAllowance = 0;

// T1: First Order (1000 USDT)
execute(
    router,
    swapExactOutputSingle(800 USDT), // Router uses less than approved
    1000e6,
    USDT,
    WETH,
    30 // 0.3% slippage
);
// Result: 200 USDT allowance remains

// T2: Second Order (2000 USDT)
execute(
    router,
    swapExactInputSingle(2000 USDT),
    2000e6,
    USDT,
    WETH,
    30
); // REVERTS: Cannot approve while previous allowance exists

Impact

  1. System Reliability

    • Order execution failures
    • Stuck transactions
    • Resource wastage
  2. Financial

    • Gas losses from failed transactions
    • Missed trading opportunities
    • Potential loss of funds in edge cases

Mitigation

function execute(
    address target,
    bytes memory txData,
    uint256 amountIn,
    IERC20 tokenIn,
    IERC20 tokenOut,
    uint16 bips
) internal returns (uint256 swapAmountOut, uint256 tokenInRefund) {
    // Reset approval if exists
    if (tokenIn.allowance(address(this), target) > 0) {
        tokenIn.safeApprove(target, 0);
    }
    
    // Set new approval
    tokenIn.safeApprove(target, amountIn);
    
    // Execute swap with safety checks
    (bool success, bytes memory result) = target.call(txData);
    require(success, "Swap failed");
    
    // Validate and process results
    // ... remaining implementation
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant