The afterOrderExecution function in GmxProxy.sol transfers tokens based on unvalidated addresses from eventData, allowing potential transfers of unauthorized tokens.
https://github.com/CodeHawks-Contests/2025-02-gamma/blob/e5b98627a4c965e203dbb616a5f43ec194e7631a/contracts/GmxProxy.sol#L250
https://github.com/CodeHawks-Contests/2025-02-gamma/blob/e5b98627a4c965e203dbb616a5f43ec194e7631a/contracts/GmxProxy.sol#L253
Faulty Code Snippet:
Unchecked Addresses: The token addresses (eventData.addressItems.items[0].value and eventData.addressItems.items[1].value) are not validated against a list of allowed tokens (e.g., collateralToken or indexToken).
Risk of Malicious Data: If eventData is manipulated (e.g., via compromised GMX callback), attackers can drain funds by specifying arbitrary token addresses.
Example Attack Scenario
Malicious Order Execution: An attacker triggers an order that populates eventData with a fake token address (e.g., attackerToken).
Unauthorized Transfer: The contract transfers attackerToken to perpVault, but since attackerToken is controlled by the attacker, they can mint unlimited tokens or re-enter the contract.
Fund Theft: Attackers can steal any ERC20 token held by GmxProxy.
Reentrancy: Malicious tokens may re-enter the contract during transfer, bypassing the state checks
Manual review
Validate that transferred tokens are collateralToken or indexToken.
After fix:
Address Validation: Added require statements to ensure only collateralToken or indexToken are transferred.
Verification
Test Case 1 (Valid Token):
eventData specifies collateralToken and indexToken.
Transfers succeed ✅.
Test Case 2 (Invalid Token):
eventData includes attackerToken.
Transaction reverts with "Invalid token" ❌.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
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.