0xGoodess - setIncentiveSettings would be halt during a rebalance operation that gets stuck due to supply cap is reached at Aave

[sherlock-admin]

0xGoodess

high

setIncentiveSettings would be halt during a rebalance operation that gets stuck due to supply cap is reached at Aave

Summary

setIncentiveSettings would be halt during a rebalance operation that gets stuck due to supply cap is reached at Aave

Vulnerability Detail

rebalance implement a cap of tradeSize and if the need to rebalance require taking more assets than the maxTradeSize, then twapLeverageRatio would be set to the targeted leverage.
twapLeverageRatio == 0 is required during rebalance.

Consider:

lever is needed during rebalance, the strategy require to borrow more ETH and sell to wstETH
during the 1st call of rebalance the protocol cache the new twapLeverageRatio
However wstETH market in Aave reach supply cap. rebalance/iterateRebalance comes to a halt.
twapLeverageRatio remains caching the targeted leverage

setIncentiveSettings requires a condition in which no rebalance is in progress. With the above case, setIncentiveSettings can be halted for an extended period of time until the wstETH market falls under supply cap.

Worth-noting, at the time of writing this issue, the wstETH market at Aave has been at supply cap

In this case, malicious actor who already has a position in wstETH can do the following:

• deposit into the setToken, trigger a rebalance.

• malicious trader withdraw his/her position in Aave wstETH market so there opens up vacancy for supply again.

• protocol owner see supply vacancy, call rebalance in order to lever as required. Now twapLeverageRatio is set to new value since multiple trades are needed

• malicious trader now re-supply the wstETH market at Aave so it reaches supply cap again.

• the protocol gets stuck with a non-zero twapLeverageRatio, setIncentiveSettings can not be called.

    function setIncentiveSettings(IncentiveSettings memory _newIncentiveSettings) external onlyOperator noRebalanceInProgress {
        incentive = _newIncentiveSettings;

        _validateNonExchangeSettings(methodology, execution, incentive);

        emit IncentiveSettingsUpdated(
            incentive.etherReward,
            incentive.incentivizedLeverageRatio,
            incentive.incentivizedSlippageTolerance,
            incentive.incentivizedTwapCooldownPeriod
        );
    }

Impact

setIncentiveSettings would be halt.

Code Snippet

https://github.com/sherlock-audit/2023-05-Index/blob/main/index-coop-smart-contracts/contracts/adapters/AaveLeverageStrategyExtension.sol#L484-L495

Tool used

Manual Review

Recommendation

Add some checks on whether the supply cap of an Aave market is reached during a rebalance. If so, allows a re-set of twapLeverageRatio

[ckoopmann]

This is another scenario, that we will investigate in more detail.

[pblivin0x]

In the listed vulnerability, it is proposed that a

malicious actor who already has a position in wstETH can deposit into the setToken, trigger a rebalance.

But I don't believe this is the case. Unpermissioned actors can mint the SetToken with exact replication via the DebtIssuanceModuleV2. In this case the leverage ratio would remain the same as before the mint and not trigger a rebalance.

I believe the current plan for avoiding any Aave supply cap issues is by imposing a SetToken supply cap.

[0xffff11]

As discussed with sponsor, valid medium

[ckoopmann]

Fixed the issue of settings being bricked in the mentioned scenario by adding an override flag that can be set by the operator:
IndexCoop/index-coop-smart-contracts@edbe0b0

Generally I don't see a way to reliably protect against hitting the supply cap, however it should not endanger users funds as redeeming as well as levering down are not affected. (only minting new set tokens as well as levering up would be blocked, which is a know limitation)

[IAm0x52]

Fix looks good. Operator can now manually override the noRebalanceInProgress modifier