search

sherlock-audit / 2024-10-gamma-rewarder-judging

7 stars 3 forks source link

MohammedRizwan - `blocksPerEpoch` can be set to any value which is against intended design i.e 6 hours - 1 day blocks duration #216

Open sherlock-admin3 opened 2 weeks ago

sherlock-admin3 commented 2 weeks ago

MohammedRizwan

Medium

blocksPerEpoch can be set to any value which is against intended design i.e 6 hours - 1 day blocks duration

Summary

blocksPerEpoch can be set to any value which is against intended design i.e 6 hours - 1 day blocks duration

Root Cause

Missing upper bound check while setting blocksPerEpoch via setBlocksPerEpoch()

Internal pre-conditions

Admin can set any desired value of blocksPerEpoch via setBlocksPerEpoch()

External pre-conditions

No response

Attack Path

1) Admin calls setBlocksPerEpoch() function to set the blocksPerEpoch. 2) blocksPerEpoch is expected to be 6 hours - 1 day worth of blocks as per intended protocol design as per contest readme but due to missing upper bound check while setting the blocksPerEpoch. 3) This missing check allows the admin to set the blocksPerEpoch to any desired value. 4) This breaks the intended design of protocol.

Impact

Due to high blocksPerEpoch, zk proof computation would be too expensive per user. The intended design is to keep it as 6 hours - 1 day worth of blocks as per contest readme, however this is not implemented in setBlocksPerEpoch() function so this breaks the intended design of protocol.

PoC

https://github.com/sherlock-audit/2024-10-gamma-rewarder/blob/main/GammaRewarder/contracts/GammaRewarder.sol#L240

As per contest readme-

blocksPerEpoch will not be set as something excessively large so as to make the zk proof computation too expensive per user. 6 hours - 1 day worth of blocks would be reasonable. This would be computed in blocks however.

Mitigation

Consider having upper bound check for blocksPerEpoch in setBlocksPerEpoch() function such that it should not exceed the intended design i.e 6 hours - 1 day worth of blocks duration.