hack3r-0m - Incompability with various ERC20 supported by morpho

[sherlock-admin4]

hack3r-0m

Medium

Incompability with various ERC20 supported by morpho

Summary

• https://github.com/sherlock-audit/2024-10-morpho-x-index/blob/main/index-protocol/contracts/protocol/modules/v1/MorphoLeverageModule.sol#L905

There are certain cases where collateralToken on morpho are composite and have underlying exposure to other assets in morpho markets.

For example, Metamorpho ERC4626 shares whose market's collateralToken is same as loanToken of new market where colalteralToken is ERc4626 share itself.

The protocol does explicitly state in readme that:

If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?

In theory any ERC20-Token (including USTD and USDC that is compatible with Morpho should also be compatible with this integration.

Exceptions are tokens that are rebasing or enforce a transfer fee which are generally not supported by Index Protocol.

Due to ERC4626 having convexity as they are exposed to collateralToken of different market itself, current leverage will not work. And price provided would be in relative terms which would further need to recursively called on base market to obtain notional price

Root Cause

• leverage and price calculation mechansim not accounting for fact the there can be recurvsively nested markets on morpho

Internal pre-conditions

N/A

External pre-conditions

• there exist a morpho market whose collateralToken is metamorpho share (or any other asset with morpho exposure). creation of such market is permissonless

Attack Path

N/A, the underlying mechanism will be broken when used with such tokens.

Impact

Several important function like:

• maintaining leverage bounds
• recentering speed implementation, etc.

won't work and will result in undefined behaviour

PoC

Same as "Attack Path"

Mitigation

• protocol should consider explicit documenting that such tokens are not supported
• modify calculations of leverage and recentering speed mechanism which are non-trivial