Skip to content

Latest commit

 

History

History
56 lines (38 loc) · 3.55 KB

075.md

File metadata and controls

56 lines (38 loc) · 3.55 KB

Fast Khaki Raccoon

Medium

Skipping interest accruals will result in a loss for users

Summary

Skipping interest accruals will result in a loss for users

Root Cause

Upon adding interest through FraxlendPairCore::addInterest(), we have this piece of code:

if (_currentUtilizationRate != 0 && _rateChange < (_currentUtilizationRate * minURChangeForExternalAddInterest) / UTIL_PREC) {
            emit SkipAddingInterest(_rateChange);
        } else {
            (, _interestEarned, _feesAmount, _feesShare, _currentRateInfo) = _addInterest();
        }

It skips interest for gas optimization purposes as explained in a comment above as according to the comment, the loss would be negligible. However, this report will explain a scenario where the loss exceeds the medium severity loss threshold.

Internal Pre-conditions

No response

External Pre-conditions

No response

Attack Path

  1. Let's imagine a scenario where the protocol hasn't been interacted with for a day, the interest of FraxlendPair is 10% and the total assets deposited are 1_000_000e18 which is 1,000,000$ (assuming a stablecoin), the share to asset ratio is 1:1, thus total supply is 1_000_000e18 as well (Fraxlend which we are forking from has ~10 million in just one of their vaults, having 1/10 of that is perfectly achievable)
  2. With the above information, the pending interest is equal to 1_000_000e18 * 0.1 / 365 = 273972602739726027397 (rounding down which makes the scenario in favour of low severity, still we will reach losses for medium severity despite rounding down)
  3. Let's imagine LendingAssetVault has 250_000e18 total assets at a 1:1 share to asset ratio and 150_000e18 of them are utilized
  4. A user who has 100_000e18 shares in LendingAssetVault wants to withdraw
  5. Upon doing that, we will skip interest accrual due to the reason explained in the root cause, this will happen if the utilization ratio hasn't changed enough, we will also skip the _updateAssetMetadataFromVault() call due to the same reason
  6. The assets the user will receive are 100000e18 * 250000e18 / 250000e18 = 100000e18, 100,000$ as the share to asset ratio is 1:1
  7. If the interest was accrued and the metadata was updated, the calculations would be the following:
  • the new vault CBR will equal 1e18 * (1000000e18 + 273972602739726027397) / 1000000e18 = 1000273972602739726 (due to the pending interest)
  • _vaultAssetRatioChange will equal 1e18 * 1000273972602739726 / 1e18 - 1e18 = 273972602739726
  • _changedUtilizedState will equal 150000e18 * 273972602739726 / 1e18 = 41095890410958900000
  • this causes the total assets to increase by 41095890410958900000, to a total of 250000e18 + 41095890410958900000 = 250041095890410958900000
  1. If the user withdrew with the accrued interest and the updated metadata (the actual legit state), he would have received 100000e18 * 250041095890410958900000 / 250000e18 = 100016438356164383560000 which equals ~100,016$ which makes the 100,000$ actually received in step 6 a loss of ~16$ and a percentage loss of ~0.016% - the losses needed for medium severity according to the rules are 10$ and 0.01%

Impact

Loss of funds. The opposite scenario is also possible where the user deposits and is immediately in profit, this results in losses for the other suppliers.

PoC

No response

Mitigation

Properly update the interest upon actions such as depositing and withdrawing