feelereth - Accrual factor is not validated to be <= 1. Could be used to manipulate interest in unexpected ways

[sherlock-admin]

feelereth

high

Accrual factor is not validated to be <= 1. Could be used to manipulate interest in unexpected ways

Summary

Accrual factor is not validated to be <= 1. Could be used to manipulate interest in unexpected ways

Vulnerability Detail

This code contains a potential vulnerability where the accrual factor returned by getAccrualFactor could be greater than 1, which could allow interest to accrue faster than expected.

The key lines are:

   function getAccrualFactor(IRateModel rateModel, uint256 utilization, uint256 dt) internal view returns (uint256) {

     // ...

     return _computeAccrualFactor(rate, dt);

   }

   function _computeAccrualFactor(uint256 rate, uint256 dt) private pure returns (uint256) {

     // ...

     return (ONE + rate).rpow(dt, ONE);

   }

The rpow function computes (ONE + rate) ** dt. If rate is very large or dt is very long, this could result in a number greater than 1.

For example, if rate = 0.5% per second (0.005e18) and dt = 1 year (31536000 seconds), the accrual factor would be 1.005 ^ 31536000 = 2.7, which is > 1.

This could allow interest to accrue much faster than expected. For example, if a deposit accrues 2x the expected interest due to this, it could break the protocol's ability to repay lenders.

Impact

This could allow interest to accrue much faster than expected. For example, if a deposit accrues 2x the expected interest due to this, it could break the protocol's ability to repay lenders. In general this is a critical severity issue that undermines the core interest mechanics of the protocol.

Code Snippet

https://github.com/sherlock-audit/2023-10-aloe/blob/main/aloe-ii/core/src/RateModel.sol#L38-L51 https://github.com/sherlock-audit/2023-10-aloe/blob/main/aloe-ii/core/src/RateModel.sol#L53-L59

Tool used

Manual Review

Recommendation

To mitigate this, the accrual factor should be capped at 1. A suggestive example:

   function _computeAccrualFactor(uint256 rate, uint256 dt) private pure returns (uint256) {

     // ...

     uint256 factor = (ONE + rate).rpow(dt, ONE);

     if (factor > ONE) {

       return ONE;

     } else {

       return factor;

      }

   }

This ensures the accrual factor can never exceed 1, preventing the interest manipulation vulnerability.

[sherlock-admin2]

3 comment(s) were left on this issue during the judging contest.

panprog commented:

invalid, because there is no problem if accrualFactor is greater than 1 - this can easily happen and no problems with this, just normal calculation

tsvetanovv commented:

I don't see a problem here

MohammedRizwan commented:

valid