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.