code-423n4 / 2021-10-tempus-findings

0 stars 0 forks source link

Lack of validation for Maturity Date #32

Open code423n4 opened 2 years ago

code423n4 commented 2 years ago

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

mijovic commented 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.

0xean commented 2 years ago

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