Part 2

Summary

The function createMarketOrder does not enforce any mechanism to limit unfavorable price fluctuations, such as slippage or a user-defined price range. This omission allows a trade to be executed at potentially extreme prices if a market fluctuation or manipulation occurs shortly before the order is finalized. As a result, users may face significant losses in the presence of front-running or other price manipulation tactics. A robust solution would involve integrating a parameter that ensures trade execution within a specified price tolerance, safeguarding users against abrupt market shifts and malicious exploitation.

Vulnerability Details

Within the createMarketOrder function, there is no mechanism to guard against sudden adverse price fluctuations (e.g., slippage protection or a maximum/minimum price range). As a result, the contract relies solely on simulateTrade for price determination without any validation that the final execution price remains within an acceptable threshold. This opens the door to front-running or price manipulation attacks, allowing malicious actors to shift the price in their favor at the time of order settlement. Consequently, users may find their trades executed at unexpectedly poor prices, leading to potentially significant financial losses.

Impact

By allowing trades to be executed without any slippage or price boundary checks, users can be exposed to abrupt and highly unfavorable price movements. Attackers can exploit this by front-running or manipulating the market, potentially causing trades to settle at severe losses for the user. Over time, repeated exploitation could result in significant financial harm, undermining user trust and the overall integrity of the protocol.

Proof of Concept

The contract allows the creation of market orders (createMarketOrder function) without offering any parameter to protect against sudden price changes (slippage) or setting an acceptable minimum/maximum price range. Consequently, orders may be executed at highly unfavorable prices for the user, especially in environments prone to front-running attacks.

Code Analysis

• OrderBranch.sol - createMarketOrder

Below is a focused excerpt of the createMarketOrder function. Notably, no slippage or price range mechanism is enforced:

Explanation

In the design of a DEX or derivatives protocol, market orders typically include a mechanism to guard against excessive price fluctuation (slippage). Here, while simulateTrade calculates a fill price, there is no verification that the final trade price remains within a user-defined tolerance. Attackers could exploit this by manipulating the price or front-running transactions, causing orders to be filled at significantly worse prices than anticipated.

Vulnerable Scenario

1. An attacker notices a user is about to send a transaction to create a market order with sizeDelta = X.

2. The attacker, aware of the absence of slippage limits, quickly places large orders that shift the price (potentially exploiting low liquidity).

3. The fillPriceX18 is determined at the time the user’s transaction is mined, leading to an unfavorable price for the user.

4. The user’s order is filled at this worse price and cannot revert, as the contract does not validate against a price threshold.

5. The attacker then unwinds their position or exploits the artificially created price difference for profit.

Confirmation

The createMarketOrder function does not include any slippage or price boundary checks to protect trades from abrupt market movements. Thus, there is a real risk of orders being executed at undesirable prices, exposing users to potential front-running and price manipulation attacks.

Tools Used

Manual Code Review
A detailed, line-by-line analysis of the contract’s source code was carried out to identify potential logic gaps. This thorough examination brought to light the absence of any slippage control or price boundary checks within the createMarketOrder function.

Recommendations

Implement a slippage tolerance or price boundary parameter within the createMarketOrder function to ensure the final execution price remains within acceptable limits. This mechanism will help prevent front-running and price manipulation, safeguarding users from unexpected adverse price movements.