Lucene search

K
code423n4Code4renaCODE423N4:2023-07-ANGLE-MITIGATION-FINDINGS-ISSUES-17
HistoryJul 21, 2023 - 12:00 a.m.

Collateralization ratio manipulation can cause a denial of service

2023-07-2100:00:00
Code4rena
github.com
4
collateralization ratio
denial of service
mitigation
overflow
stablecoin redemption
profit accrual
savingsvest contract
redeemer contract
root cause
manual review
recommended mitigation
under/overflow
code-423n4
angle documentation
safecast
openzeppelin library

Lines of code

Vulnerability details

Impact

Stablecoin redeeming and profit accruing in the SavingsVest contract can be blocked when the collateralization ratio has overflown.

Proof of Concept

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:

  1. the report recommends using SafeCast library from OpenZeppelin to cast the computed collateralization ratio to uint64;
  2. the used SafeCast.toUint64 function reverts when the passed value is greater than the maximal value of uint64.

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.

Tools Used

Manual review

Recommended Mitigation Steps

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.

Assessed type

Under/Overflow


The text was updated successfully, but these errors were encountered:

All reactions