Stablecoin redeeming and profit accruing in the SavingsVest contract can be blocked when the collateralization ratio has overflown.
The mitigation recommended in #31 and implemented by the sponsor in this commit doesn’t resolve the root cause of the issue and introduces another issue.
As per the original report, an overflow of the collatRatio would result in a wrong value of the variable. After the applied mitigation, an overflow in the variable will result in a denial of service because:
Thus, after the recommended mitigation is implemented, an overflow of the collatRatio variable will make all calls to the LibGetters.getCollateralRatio function revert since the call to toUint64 will always revert due to the overflown value of the collateralization ratio. LibGetters.getCollateralRatio is called by the accrue function of the SavingsVest contract and by the redeem function of the Redeemer contract–these operations won’t be possible after the collateralization ratio has overflown.
As report #9 demonstrates, the collateralization ratio can be overflown by donating a small value of stablecoins. Thus, the attack is cheap for the attacker, but blocks redeeming and accrual for all users of the protocol.
Manual review
It seems that the recommendation in the duplicate report #9 correctly addresses the root cause of the issue: the developers need to decide what’s the maximal value for the collateralization ratio and what it means for the protocol when the actual value is bigger. Setting the ratio to type(uint64).max, as suggested by the report, sounds reasonable.
Under/Overflow
The text was updated successfully, but these errors were encountered:
All reactions