PerpetualVault::getUserDeposits return array could lead to incorrect withdrawals
Vulnerability Details
PerpetualVault::getUserDeposits returns an array of deposit IDs, which can be used as parameters in the PerpetualVault::withdraw function. Every time a user makes a withdrawal, the last item in the array is moved to the spot vacated. This could lead to a user getting something like [15, 4, 9, 30, 22] from PerpetualVault::getUserDeposits. If the user is an externally owned contract using array indices for withdraw parameter, it could lead to them withdrawing the wrong deposit. This could also happen if the user forgets to double-check the PerpetualVault::depositInfo for their deposit ID.
Impact
The impact is proportional to the amount difference between the IDs swapped. If the amount is the same, the impact is minimal. If the user accidentally withdraws the ID with 10X the amount they meant to withdraw, it interferes with the purpose of the contract and may lead to financial losses and poor user experience.
Recommendations
There should be some way to double check the deposit amount associated with the ID to be withdrawn. This can be done by PerpetualVault::getUserDeposits itself or the deposit amount could be required as a function parameter for PerpetualVault::withdraw to check that users are withdrawing the deposit amount that they expect.
Lead Judging Commences
Suppositions
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.
Users mistake, only impacting themselves.
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.
Suppositions
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.
Users mistake, only impacting themselves.
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.
Prize pool breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.