Liquidity Management

Summary

GmxProxy.sol encodes and forwards parameters for GMX interactions (e.g. in the createOrder and settle functions) without performing internal validations on critical values such as sizeDeltaUsd, collateral amounts, and swap paths. While access is restricted to the trusted perpVault, any malformed data from upstream could result in unintended behavior.

Vulnerability Details

• Issue:
  Input parameters taken from an OrderData struct are passed directly to external calls (via gExchangeRouter.createOrder) without sufficient validation or sanity checks.

• Context:
  The contract assumes that the calling perpetual vault (perpVault) will always supply correct and validated data. There is no redundancy within GmxProxy to enforce proper bounds or to verify that parameters like sizeDeltaUsd or initialCollateralDeltaAmount fall within expected ranges.

• Inter‑Contract Considerations:
  Even though the function caller is assumed to be trusted, any breach or misconfiguration in the upstream contract could lead to erroneous or malicious data being processed.

Impact

• Order Misconfiguration:
  Invalid parameters may result in orders that are overleverage, undercollateralized, or even rejected by GMX, affecting order execution.

• Economic Losses:
  Incorrect order parameters could be exploited to gain an unfair advantage or cause economic damage to the protocol.

• System Reliability:
  The overall stability of the system may be compromised if orders are processed with invalid data, leading to unintended interactions with GMX.

POC:

Overview

This PoC demonstrates that GmxProxy’s createOrder function forwards parameters (from an OrderData structure) to the GMX router without internal validations. By providing malformed data, an attacker (or a misbehaving trusted contract) could trigger unintended behavior or misconfigured orders.

Actors

• Attacker: A malicious (or compromised) perpetual vault that supplies malformed order data.

• Victim: The GmxProxy contract that does not perform its own validation.

• Protocol: The system expecting properly validated data from the trusted perpVault.

Working Test Case

Detailed Exploit Scenario

1. Setup:

   • Deploy the GmxProxy contract (or use an existing instance).

   • Deploy the MaliciousPerpVault contract with the GmxProxy address.

2. Attack Execution:

   • The malicious vault (acting as the trusted perpVault) calls testInvalidOrder().

   • The contract constructs an OrderData payload with invalid parameters (e.g, zero for sizeDeltaUsd and an empty swap path).

   • The payload is passed to createOrder without any internal validations in GmxProxy.

3. Result:

   • The GmxProxy forwards the invalid parameters to the GMX router.

   • This may lead to misconfigured orders, unexpected reverts, or even orders that could be exploited for economic gain.

Tools Used

Manual Code Review

Recommendations

• Input Validation:
  Add explicit checks for key parameters (e.g., ensure sizeDeltaUsd > 0, collateral amounts within acceptable ranges, and valid token addresses).

• Sanity Checks:
  Validate swap paths and other array inputs to ensure they are non-empty and meet protocol expectations.

• Defense in Depth:
  Even though the perpVault is assumed to be trusted, incorporating additional validations within GmxProxy increases overall system robustness.