1inch logo

1inch Limit Order Protocol Update Security Review Report

November 2023

Overview

This audit covered an update to the Limit Order Protocol of 1inch Network. Our security assessment was a full review of the new smart contract, spanning a total of 1 week. During our audit, we have identified 1 medium severity vulnerability, which could result in a taker paying more than anticipated using a carefully constructed maker order. The reported issue was acknowledged by the development team and marked as user risk.

Scope

The analyzed resources are located on:

https://github.com/1inch/limit-order-settlement/commit/ff7909c4f32bee8879211607275dc30d788afee8

Summary

Total number of findings
1

Weaknesses

This section contains the list of discovered weaknesses.

ONN-1. MALICIOUS MAKER CAN SIPHON THE EXCESS OF TAKER'S APPROVED TOKENS

Severity:

Medium

Status:

Acknowledged

Path:

SettlementExtension.sol

Description:

A malicious maker can trick a benign taker into paying an exorbitant price for filling the order and bypass takerTraits.threshold() protection.

The _parseFeeData() function of SettlementExtension calculates integrationFee, which is further deducted from the taker inside postInteraction(). The value of integrator address comes directly from extraData. While the integrationFee value is calculated as follows.

integrationFee = actualTakingAmount * uint256(uint32(bytes4(extraData[20:24]))) / _TAKING_FEE_BASE;

Where 4-byte extraData[20:24] comes from extraData and may contain a maximum value up to 4.3 times bigger than _TAKING_FEE_BASE.

uint256 private constant _TAKING_FEE_BASE = 1e9;

The postInteraction() function is called as the last step of the order filling and aims for the maker to handle funds interactively.

Where extraData comes from the extension of the order (extension.postInteractionTargetAndData()), and the maker fully controls extension calling parameters.

  1. The benign taker makes an excessive approval to the SettlementExtension contract.
  2. The malicious maker creates an order with extension parameters that transfers an excessive amount of approved order.takerAsset.get() tokens to the address controlled by the maker.
  3. The malicious maker tricks the taker to fill the order.
  4. Although takerTraits.threshold() is specified, the taker loses their tokens since threshold protection isn't applied for the post-interaction step. Commentary from the client:

Won't fix. As resolvers are professional traders they expect to properly validate orders including the fee part as well. Also we don't feel that severity of the issue is High, because all the order parameters are known beforehand, so resolver can properly calculate what amount they will be charged upon filling the order.

Remediation:

The _parseFeeData() should limit the maximum fees the taker pays.

Table of contents