Open code423n4 opened 3 years ago
If this is true, that means that we don't understand how exchangeRateStored
works (quite likely).
Our understanding was that exchangeRateStored
is an increasing accumulator, same as chi
in MakerDAO which is both an exchange rate and an accummulator.
If exchangeRateStored
can go down in value, as well as up, we might have to revisit how we source it.
Isn't valid issue. totalBorrows
is increased while totalCash
is decreased.
So, the exchangeRateStored isn't going up or going down.
Handle
shw
Vulnerability details
Impact
A user can artificially increase the chi accrual (after maturity) by flash borrow on Compound, which affects the exchange rate used by the chi oracle. As a result, the user redeems more underlying tokens with the same amount of fyTokens since the accrual is larger than before.
Proof of Concept
The
exchangeRateStored
used by chi oracle is calculated based on thetotalBorrows
ofCToken
, which can be artificially increased by a large amount of borrow operated on Compound. Consider a user performing the following steps in a single transaction (assuming that the fyToken is matured):redeem
The user only needs to pay for the gas fees of borrowing and repaying (since they happen in the same transaction) but can redeem more underlying tokens than a regular redeem.
Referenced code: CompoundMultiOracle.sol#L46 FYToken.sol#L125 FYToken.sol#L132-L143
Recommended Mitigation Steps
Make the chi accrual time-weighted to mitigate the manipulation caused by flash borrow and repay.