The DoS in getUserDeposits arises from unbounded loops, which can be exploited by creating a large number of deposits. Functions like getUserDeposits iterate over EnumerableSet, which could run out of gas if the set grows too large. the GMX callback functions (afterOrderExecution, afterOrderCancellation) fails due to gas limits,
The getUserDeposits function iterates over an EnumerableSet to retrieve all deposit IDs for a user. If a user has a large number of deposits, this function could run out of gas, causing the transaction to fail.
An attacker repeatedly calls the deposit function to create a large number of deposits (e.g., 10,000 deposits).
Each deposit is small (e.g., 1 wei) to minimize cost.
Trigger DoS:
A legitimate user or external contract calls getUserDeposits to retrieve the deposit IDs for the attacker's address.
The function iterates over the large EnumerableSet, consuming excessive gas and eventually running out of gas.
Below is a simplified PoC to demonstrate the DoS vulnerability
Deploy the PerpetualVault contract.
Deploy the Attack contract, passing the address of the PerpetualVault contract.
Call the attack function on the Attack contract to create 10,000 deposits.
Call getUserDeposits on the PerpetualVault contract with the attacker's address.
Observe that the transaction runs out of gas and fails.
The getUserDeposits function fails, preventing the user or contract from retrieving deposit IDs.
If this function is used in critical operations (e.g., withdrawals), the entire system could be disrupted.
Manual Code Reviiew
Implement pagination to limit the number of items returned in a single call.
Example:
Restrict the number of deposits a single user can create.
Example:
Optimize gas usage in loops by minimizing storage reads and writes.
Use an off-chain service to index deposit IDs and provide them via an API.
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.
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.
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.