Protocol assumes that all future collateral and prices will have 18 decimals

[c4-submissions]

Lines of code

https://github.com/code-423n4/2023-11-kelp/blob/main/src/LRTDepositPool.sol#L109

Vulnerability details

Impact

The sponsor will provide support for additional LSTs if Eigenlayer accepts them. They may also switch to a different oracle if a better one becomes available.
Therefore, I took time to explore potential issues that could arise if more LSTs are supported or the oracle is replaced in this system.

The exchange rate cannot be accurately calculated or utilized if the collateral token or the price return by any orale does not have 18 decimal places.
If it uses more decimals, users will appear way more deposited than they are.
If it uses less decimals, users will appear way less deposited than they are.
As a result, users may be able to withdraw significantly more reETH than they should be able to or they may mint significantly less than expected.

Proof of Concept

LRTDepositPool.sol

    function getRsETHAmountToMint(
        address asset,
        uint256 amount
    )
        public
        view
        override
        returns (uint256 rsethAmountToMint)
    {
        address lrtOracleAddress = lrtConfig.getContract(LRTConstants.LRT_ORACLE);
        ILRTOracle lrtOracle = ILRTOracle(lrtOracleAddress);

        // calculate rseth amount to mint based on asset amount and asset exchange rate
        // @audit rsETH has 18 decimals
        // @audit `lrtOracle.getRSETHPrice()` has 18 decimals
        // @audit Therefore, Protocol assumes `(amount * lrtOracle.getAssetPrice(asset))` has 36 decimals
        rsethAmountToMint = (amount * lrtOracle.getAssetPrice(asset)) / lrtOracle.getRSETHPrice();
    }

Attacker can drain the contract by minting a large number of tokens if the system supports LSTs with more than 18 decimals. The same risk applies if the oracle has more than 18 decimals.

Tools Used

VS Code

Recommended Mitigation Steps

Do not assume that LSTs or price oracles have 18 decimals.

Assessed type

Decimal

[c4-pre-sort]

raymondfam marked the issue as sufficient quality report

[c4-pre-sort]

raymondfam marked the issue as duplicate of #97

[c4-pre-sort]

raymondfam marked the issue as duplicate of #479

[c4-judge]

fatherGoose1 changed the severity to 2 (Med Risk)

[c4-judge]

fatherGoose1 marked the issue as satisfactory

[c4-judge]

fatherGoose1 changed the severity to QA (Quality Assurance)

[c4-judge]

fatherGoose1 marked the issue as grade-b