Mathisen Marketing

Your Marketing Blog

1Inch Audit – LimitOrder Protocol

1inch logo

As an affiliate, we may earn from qualifying purchases. We get commissions for purchases made through links on this website.

Receive $10 in Bitcoin when you buy or sell $100 or more on Coinbase! https://mathisenmarketing.com/coinbase

CoinFabrik was asked to review 1 inch Limit Order Protocol contracts. Limit orders are agreements between the manufacturer, who creates the order, and the recipient, who accepts the order. The author defines an order (offchain) that contains a pair of tokens, an exchange rate and the total amount he wants to exchange – among other parameters. The recipient accepting this order can fill the order and execute it if certain conditions are met.

We have checked the contracts. a summary of our findings, what their current status is, and then we show the details of our findings.

We analyze contracts from a private github repository: 1inch/limit-order-protocol (github.com)

This inspection is based on the following commitment: fc528b390bad66927b9316470e4c86d06df58563

Contracts

The audited contracts are:

  • contracts/LimitOrderProtocol.sol: main functions
  • contracts/helpers/AmountCalculator.sol: helper functions calculating maker and taker amounts
  • contracts/helpers/PredicateHelper.sol: helper functions for building predicates
  • contracts/helpers/ImmutableOwner.sol: modifier
  • contracts/helpers/ERC20Proxy.sol: proxy helper
  • contracts/helpers/ERC1155Proxy.sol: proxy helper
  • contracts/helpers/ERC721Proxy.sol: proxy helper
  • contracts/helpers/NonceManager.sol: nonces
  • contracts/libraries/ArgumentsDecoder.sol: help decoding arguments
  • contracts/libraries/UncheckedAddress.sol: includes calls to (external) token functions
  • contracts/interfaces/IEIP1271.sol: interface
  • contracts/interfaces/InteractiveMaker.sol: interface

Analyzes

The following analyzes were performed:

  • Abuse of different calling methods
  • Integer overflow errors
  • Division with zero error
  • An outdated version of the Solidity compiler
  • Ahead running attacks
  • Recovery attacks
  • Abuse of block timestamps
  • Softlock denial of service attacks
  • Works with excessive gas costs
  • Missing or misused function identifiers
  • Unnecessarily complex code and contract interaction
  • Poor or non-existent error handling
  • Failure to use the cancellation model
  • Insufficient validation of input parameters
  • mishandling of cryptographic signatures

Specific analyzes for this project

We continued to test for design flaws that allow makers/takers to exploit each other. This includes the following analyses:

  1. We tested whether receivers were able to fill orders with malicious parameters, allowing them to take advantage of makers with, for example, an improved TakeAmount / makingAmount ratio.
  2. We tested the boundary conditions by adapting the provided truffle tests to security-relevant scenarios.
  3. Finally, since the contract makes calls to external contracts based on parameters, we look for vulnerabilities resulting from these calls.

Observations and corrections

id Title Stability Status
CR-1 A front-running attack in adverse order results in an arbitrary speed set by the manufacturer Critical Corrected
IN SECTION 1 Use of deprecated functions Enhancement Not fixed

Severity rating

Security risks are classified as follows:

  • Critical: These are things we manage to exploit. They seriously compromise the system. They must be repaired immediately.
  • Medium: These are potentially exploitable problems. Even if we did not manage to exploit them or their effect is not clear, they may pose a security risk in the near future. We recommend fixing them as soon as possible.
  • Minor: These issues are issues that are relatively minor or difficult to exploit, but can be exploited in conjunction with other issues. Such problems do not prevent deployment in production environments. They should be taken into account and corrected if possible.
  • Enhancement: Such observations do not constitute a security risk. Those are the best practices we recommend you implement.

This classification is summarized in the following table:

STABILITY USEFULLY ROADBLOCK TO BE REPAIRED
Critical Yeah Yeah Immediately
Medium In the near future Yeah As soon as possible
Small Unlikely No Eventually
Enhancement No No Eventually

Critical severity

CR-01 Front running attack in adverse order results in arbitrary speed setting by manufacturer (fixed)

The LimitOrder contract allows a maker to specify orders with (among other things) makingAmount, takeAmount, getMakerAmount, and getTakerAmount parameters set. When a taker calls fillOrder, the exchange’s makeAmount and takeAmount values ​​are calculated on the fly, and can use these maker-defined getMakerAmount and getTakerAmount functions arbitrarily.

A malicious maker can create order setup custom getMakerAmount and getTakerAmount functions on an arbitrary maker-driven contract along with a different makeAmount/takingAmount price. The maker’s contract could be implemented so that if the taker evaluates these getMakerAmount and getTakerAmount values, it will get the original makingAmount and takeAmount values ​​of the order. However, when the recipient calls fillOrder() when makeAmount is set to 0, the maker can perform a preemptive attack by calling the setter in the maker’s malicious contract, which modifies the value returned by getMakerAmount. Thus, when fillOrder executes, it uses a new value that may be less than the value expected by the receiver (makingAmount). (Similarly, takeAmount=0 and getTakerAmount.)

Recommendation

The expected behavior of FillOrder should be documented, and in particular the purpose of thresholdAmount, getMakerAmount and getTakerAmount, so that the parties are fully aware of the possible execution results of the order.

Tracking

1inch implemented a solution that eliminates the threat by adding a parameter, thresholdAmount, to fillOrder that the receiver uses to stop the attack.

Before making bank transfers, fillOrder’s code requires it

takingAmount <= thresholdAmount

while takeAmount specifies and requires getMakerAmount

makingAmount >= thresholdAmount

when makeAmount defines getMakerAmount.

The solution therefore eliminates the threat in the event that the taker enters the thresholdAmount according to their needs: for example, a taker who sets a non-zero makingAmount in fillOrder can set a thresholdAmount equal to the takeAmount he expects to receive (so that the maker cannot increase the order intake amount); similarly, a taker entering a takeAmount into fillOrder can set the thresholdAmount to match the expected makingAmount (so that the maker cannot reduce the order’s makingAmount). When the thresholdAmount values ​​differ from what the recipient expects to receive, this can prevent the transaction from happening or allow the author to benefit.

An alternative solution, proposed and rejected by 1 inch, involves a different additional parameter, minPrice, which is added to fillOrder and the contract requires that

makingAmount * 1e18 / takingAmount >= minPrice.

This solution is analogous to the thresholdAmount solution. In general, the recipient may find it problematic to pay the entered price when calling fillOrder(); he may even reject thresholdAmount (or minPrice) because he expects the order to be executed according to what he inputs without losing to additional steps.

Medium severity

No problems.

Low severity

No problems.

Improvements

FI-01 Use of obsolete functions

Activities remaining() and fillOrder() utilize value1.sub(value2, error_message) which is obsolete (see link).

Recommendation

Use trySub() instead.

We noticed that the contracts were concise and there were few documents. The code shrinks to a single contract. The tests and test scripts contained in the archive helped to understand the execution flow of border assignments and also to evaluate certain scenarios. We have included checks in the analysis to design for deficiencies specific to this model.

1 inch discovered a critical issue that allows a malicious manufacturer to defraud recipients of receiving a lower than expected exchange rate. The problem was fixed by giving the receiver a security parameter that ensures that attacks are not possible when the parameter is chosen respecting his expectations.

Disclaimer: This audit report is not a guarantee of safety, Investment advice or endorsement of the 1 inch project as CoinFabrik has not audited its platform. In addition, it does not provide a guarantee that the smart contract code is error-free.

Receive $10 in Bitcoin when you buy or sell $100 or more on Coinbase! https://mathisenmarketing.com/coinbase

Source link

Leave a Reply

Your email address will not be published. Required fields are marked *

Latest Posts

  • Curve DAO, Solana, FTX falls drastically

    Curve DAO, Solana, FTX falls drastically

    Receive $10 in Bitcoin when you buy or sell $100 or more on Coinbase! https://mathisenmarketing.com/coinbase Crypto prices today: After three days of positive trading, crypto prices seem to be moving back into slow territory. All major coins have gone red. Curve DAO Token is down 7.78%. Solana is down 6.27% in the last 24 hours. […]

    Read More

  • BTC Dominance On A Decline

    BTC Dominance On A Decline

    Receive $10 in Bitcoin when you buy or sell $100 or more on Coinbase! https://mathisenmarketing.com/coinbase Bitcoin (BTC) has been under heavy selling pressure. In the last 24 hours, the price of Bitcoin decreased by 2.47%. According to a recent update from onchain data provider Glassnode, bitcoin shrimp balance has hit an all-time high since the […]

    Read More