The design of delegate mechanism is users can only delegate to longer lock than current lock. And users have to undelegate before they can withdraw their tokens.
So delegatee might spam to increase end value to maximum to block users from withdrawing. Users want to withdraw now have to increase their locks to maximum value first and have to wait that long before they can withdraw. Or if they use quitLock() they basically receive nothing because when lock time is maximum, penalty is 100% of lock amount.
Proof of Concept
Consider the scenario
Alice create a lock and delegate it to Bob
Bob became malicious and spam increaseUnlockTime() to maximum value.
Alice want to withdraw have to increaseUnlockTime() to the same value as Bob.
Now Alice has 2 choices, wait that long before she can withdraw her token back or call quitLock() and receive tiny amount since the penalty could be up to 100%.
Recommended Mitigation Steps
Should design a mechanism to allow users to undelegate and withdraw
Lines of code
https://github.com/code-423n4/2022-08-fiatdao/blob/fece3bdb79ccacb501099c24b60312cd0b2e4bb2/contracts/VotingEscrow.sol#L555
Vulnerability details
Impact
The design of delegate mechanism is users can only delegate to longer lock than current lock. And users have to undelegate before they can withdraw their tokens.
So delegatee might spam to increase
end
value to maximum to block users from withdrawing. Users want to withdraw now have to increase their locks to maximum value first and have to wait that long before they can withdraw. Or if they usequitLock()
they basically receive nothing because when lock time is maximum, penalty is 100% of lock amount.Proof of Concept
Consider the scenario
increaseUnlockTime()
to maximum value.increaseUnlockTime()
to the same value as Bob.quitLock()
and receive tiny amount since the penalty could be up to 100%.Recommended Mitigation Steps
Should design a mechanism to allow users to undelegate and withdraw