Liquidity Management

Summary

https://github.com/CodeHawks-Contests/2025-02-gamma/blob/e5b98627a4c965e203dbb616a5f43ec194e7631a/contracts/GmxProxy.sol#L371-L451

The createOrder function in GmxProxy.sol does not validate the orderData parameters, which could lead to invalid orders being created.

Vulnerability Details

The function does not check if orderData.market, or orderData.initialCollateralToken are valid addresses.
It also does not validate the orderData.sizeDeltaUsd or orderData.amountIn values, which could lead to invalid or malicious orders.

Conceptual Scenario: Exploiting Lack of Input Validation in createOrder Function

Participants:

Alice: A legitimate user who interacts with the GmxProxy contract to create valid orders.

Bob: A malicious attacker who exploits the lack of input validation in the createOrder function.

GmxProxy: The vulnerable smart contract that allows users to create orders on the GMX protocol.

Step 1: Alice Creates a Valid Order

Alice uses the createOrder function in the GmxProxy contract to create a valid order. She provides the following parameters:

• orderData.market: A valid GMX market address.

• orderData.initialCollateralToken: A valid collateral token address.

• orderData.sizeDeltaUsd: A reasonable size for the order (e.g., 10,000 USD).

• orderData.amountIn: A reasonable amount of collateral (e.g., 1,000 tokens).

The order is successfully created and executed by the GMX protocol.

Step 2: Bob Prepares for the Attack

Bob notices that the createOrder function does not validate the input parameters. Specifically:

• The function does not check if orderData.market or orderData.initialCollateralToken are valid addresses.

• The function does not validate the values of orderData.sizeDeltaUsd or orderData.amountIn.

• Bob decides to exploit this by creating invalid or malicious orders.

Step 3: Bob Creates an Invalid Order

Bob calls the createOrder function with the following malicious parameters:

• orderData.market: address(0) (an invalid address).

• orderData.initialCollateralToken: address(0) (an invalid address).

• orderData.sizeDeltaUsd: 0 (an invalid size).

• orderData.amountIn: 0 (an invalid amount).

Since the createOrder function does not validate these parameters, the order is created and submitted to the GMX protocol.

Step 4: GMX Protocol Processes the Invalid Order

The GMX protocol attempts to process the invalid order but fails because:

• The orderData.market address is invalid, so the market does not exist.

• The orderData.initialCollateralToken addresses is invalid, so the tokens do not exist.

• The orderData.sizeDeltaUsd and orderData.amountIn values are zero, so the order has no size or collateral.

The GMX protocol rejects the order, but the GmxProxy contract has already consumed gas and resources to create the order.

Step 5: Bob Repeats the Attack

Bob repeats this process multiple times, creating numerous invalid orders.

Each invalid order consumes gas and resources, potentially causing the GmxProxy contract to run out of funds or become unresponsive.

Step 6: Impact on the Protocol
The GmxProxy contract becomes clogged with invalid orders, leading to:

• Loss of Funds: Gas is wasted on creating invalid orders, depleting the contract's ETH balance.

• Unexpected Behavior: The contract may fail to process legitimate orders due to resource exhaustion.

• Reputation Damage: Users lose trust in the protocol due to its inability to handle invalid inputs.

Impact

Invalid orders could be created, leading to loss of funds or unexpected behavior.

Tools Used

manual review

Recommendations

• Add input validation for all parameters in the createOrder function.

• Ensure that orderData.market, and orderData.initialCollateralToken are valid addresses.

• Validate that orderData.sizeDeltaUsd and orderData.amountIn are within reasonable bounds.