Open code423n4 opened 2 years ago
maturityTime
is clearly exposed to the user, can be checked before depositing funds.
Also, all the fees are also public.
I really don't get what else should we check besides that maturityTime
is greater than the current block timestamp.
When designing the protocol we didn't want to limit the length of the pool to some minimal value.
setting a minimum maturity time (from block.timestamp) does not mitigate the risk of user depositing funds if they are totally un-aware of the maturityTime.
Validating the parameter is some minimum amount of time in the future could avoid a fat finger type error, but this should be non-critical
Handle
Koustre
Vulnerability details
Impact
When the TempusPool contract is deployed, one of the deployment parameters is a maturity date that is passed as a Unix timestamp. Currently, the only validation rule that is set is to make sure the maturity date is not set before the current block that it is being deployed.
The consequence of this is that users may incorrectly deposit their tokens into the pool and when attempting to recover their tokens have to pay the early redemption fee, costing user funds.
Proof of Concept
Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept.
https://github.com/code-423n4/2021-10-tempus/blob/63f7639aad08f2bba717830ed81e0649f7fc23ee/contracts/TempusPool.sol#L66-L100
Tools Used
Recommended Mitigation Steps
Input validation checks for the maturity time to avoid fat fingering