The withdrawal function in the PerpetualVault contract relies on block.timestamp to enforce a lock period before funds can be withdrawn. This approach is vulnerable because block timestamps can be manipulated by miners/validators within a small margin, potentially allowing withdrawals to occur sooner than intended.
In the withdraw function, the contract checks that the deposit's timestamp plus the lock time is less than the current block.timestamp:
Because miners or validators can adjust block.timestamp by a few seconds (or, in some cases, slightly more), an attacker with influence over block production could manipulate the timestamp to bypass this check and withdraw funds before the lock period expires.
Premature Withdrawals: An attacker with block production power could potentially withdraw funds before the intended lock period, undermining the vault’s intended security model.
Financial Exploitation: This vulnerability could be exploited to create timing attacks where withdrawals occur prematurely, possibly impacting the vault’s balance and user share distribution.
Manual Analysis
Use Block Numbers for Lock Periods: Consider using block numbers as a proxy for time since they cannot be manipulated like timestamps. For example, define a constant number of blocks per lock period.
Combine Time and Block Number Checks: To increase security, implement a dual check that uses both block.timestamp and block numbers to enforce the lock period.
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.