The setPerpVault function in GmxProxy.sol implements access control using tx.origin instead of msg.sender, creating vulnerability that allow unauthorized users to modify critical protocol parameters through phishing attacks.
Code snippet:\
The vulnerability stems from using tx.origin for authorization. While tx.origin points to the original transaction sender, it doesn't securely identify the immediate caller of the function. This creates an attack vector where a malicious contract can act as a proxy between the owner and the target contract.
An attacker could:
Deploy a malicious contract that forwards calls to setPerpVault
Trick the owner into interacting with the malicious contract
The malicious contract could then modify the perpVault address and callback settings
This could potentially lead to fund loss or protocol manipulation depending on how the perpVault is used in the system.
PoC:
The GmxProxy contract represents the vulnerable contract using tx.origin for authentication.
The AttackerContract is the malicious contract that:
Takes the target contract address in its constructor
Has a seemingly legitimate claim() function to trick the owner
Actually calls setPerpVault() when the owner interacts with it
The attack flow:
Attacker deploys AttackerContract
Attacker creates a UI or sends the owner a link to interact with claim()
When owner calls claim(), the tx.origin will be the owner's address
The malicious contract can then call setPerpVault() and pass the authorization check
The perpVault is changed to an attacker-controlled address
Manual Review
Replace tx.origin with msg.sender:
Implement proper access control using OpenZeppelin's Ownable contract:
Consider implementing a time-lock mechanism for sensitive parameter changes to provide additional security.
Lightchaser: Medium-5
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.