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.