The createOrder
and settle
function in the GMXProxy contract relies on tx.gasprice
to estimate the gas fee for order execution. This approach is unreliable, as tx.gasprice
can fluctuate or be manipulated, leading to incorrect gas fee estimations and potential transaction failures.
The issue arises because tx.gasprice
is used to calculate the position execution fee in the createOrder
and settle
function. Gas prices are highly variable and subject to network congestion, which makes them an unreliable source for transaction fee estimation. If the gas price is incorrectly estimated:
Transaction Failures: If the gas price is underestimated, the contract will not have enough funds to execute the transaction.
Overpayment: Overestimation of the gas price could result in the user overpaying for the transaction.
This breaks the correctness and reliability guarantees of the system. A malicious actor or fluctuating gas prices could exploit this to cause failures or waste gas.
The impact of this issue is significant because:
Transaction Failures: Incorrect gas fee estimation could prevent the execution of critical transactions, such as orders or swaps, affecting user experience and protocol operations.
Overpayment of Fees: Users may unnecessarily overpay gas fees, leading to potential loss of funds.
Scalability Issues: As the system scales, more orders and transactions will rely on this faulty gas price estimation, amplifying the impact.
This issue is rated as Medium because it directly affects transaction execution and user experience, though it doesn’t lead to immediate loss of funds or critical vulnerabilities.
The likelihood of this issue occurring is high, given that:
Gas prices are volatile and can fluctuate significantly based on network conditions.
The reliance on tx.gasprice
means that the system does not adapt to actual transaction costs.
As the protocol scales and interacts with more users, the frequency of failed or overpaid transactions will increase.
This is likely to become a pressing issue as the protocol grows and handles a higher volume of orders.
A Proof of Concept (POC) is not necessary for this vulnerability. The issue is caused by the inherent flaw in using tx.gasprice
, which is a well-understood vulnerability. Any scenario where the gas price differs from the true execution cost will expose this vulnerability.
Replace the reliance on tx.gasprice
with a more reliable gas estimation mechanism, such as a dynamic gas oracle or accurate estimation based on network conditions.
Suggested Code Fix:
Impact: Medium
Likelihood: High
The frontrunner won’t trigger "congestion" without a huge amount of transactions, and it will cost a lot. Moreover, the execution gas limit is overestimated to prevent such cases: ``` executionGasLimit = baseGasLimit + ((estimatedGasLimit + _callbackGasLimit) * multiplierFactor) / PRECISION; ``` The keeper won’t wait long to execute the order; otherwise, GMX would not be competitive.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.