Lybra Finance - Brenzee's results

Lines of code

https://github.com/code-423n4/2023-06-lybra/blob/481520a1440e2637e94c1200e798841b47825a91/contracts/lybra/miner/ProtocolRewardsPool.sol#L201

Vulnerability details

Impact

In ProtocolRewardsPool.getReward function, peUSDBalance gets compared to eUSD shares, which may cause unexpected actions for user, who is trying to withdraw his reward, and for protocol, who unexpectedly would send different tokens.

Proof of Concept

In getReward:L201 function checks, if peUSDBalance >= reward - eUSDShare.

                if(peUSDBalance >= reward - eUSDShare) {
                    peUSD.transfer(msg.sender, reward - eUSDShare);
                    emit ClaimReward(msg.sender, EUSD.getMintedEUSDByShares(eUSDShare), address(peUSD), reward - eUSDShare, block.timestamp);
                } else {
                    if(peUSDBalance > 0) {
                        peUSD.transfer(msg.sender, peUSDBalance);
                    }
                    ERC20 token = ERC20(configurator.stableToken());
                    uint256 tokenAmount = (reward - eUSDShare - peUSDBalance) * token.decimals() / 1e18;
                    token.transfer(msg.sender, tokenAmount);
                    emit ClaimReward(msg.sender, EUSD.getMintedEUSDByShares(eUSDShare), address(token), reward - eUSDShare, block.timestamp);
                }

The issue is that peUSDBalance is not the same as eUSD shares. Proof - in converToPeUSD function in PeUSDMainnetStableVision.sol contract eusdAmount, not eUSD share, gets converted to peUSD token.

This means that getReward contract may unexpectedly send configurator.stableToken instead of peUSD token, which may be a loss for a protocol.

Tools Used

Manual review

Recommended Mitigation Steps

Make sure that peUSDBalance gets converted to shared before it is compared to reward and eUSDShare

Assessed type

Context

Lines of code

https://github.com/code-423n4/2023-06-lybra/blob/824de2eefa30101622b65e43b79886667abad916/contracts/lybra/miner/EUSDMiningIncentives.sol#L153-L154 https://github.com/code-423n4/2023-06-lybra/blob/824de2eefa30101622b65e43b79886667abad916/contracts/lybra/miner/EUSDMiningIncentives.sol#L188-L190

Vulnerability details

Impact

Malicious users can manipulate the etherInLp and lbrInLp values which are used to calculate staked LBR LP value. As a result - malicious users in that way can purchase other people's earnings by manipulating the token amount in WETH/LBR Uniswap V2 pool with flash swaps, when it should not be possible.

Proof of Concept

The function stakedLBRLpValue calculates the user's value of staked tokens in ethlbrStakePool

    function stakedLBRLpValue(address user) public view returns (uint256) {
        uint256 totalLp = IEUSD(ethlbrLpToken).totalSupply();
        (, int etherPrice, , , ) = etherPriceFeed.latestRoundData();
        (, int lbrPrice, , , ) = lbrPriceFeed.latestRoundData();
        uint256 etherInLp = (IEUSD(0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2).balanceOf(ethlbrLpToken) * uint(etherPrice)) / 1e8;
        uint256 lbrInLp = (IEUSD(LBR).balanceOf(ethlbrLpToken) * uint(lbrPrice)) / 1e8;
        uint256 userStaked = IEUSD(ethlbrStakePool).balanceOf(user);
        return (userStaked * (lbrInLp + etherInLp)) / totalLp;
    }

This function's returned value is used in the isOtherEarningsClaimable function, which determines if the user's earnings can be claimable by others.

    function isOtherEarningsClaimable(address user) public view returns (bool) {
        return (stakedLBRLpValue(user) * 10000) / stakedOf(user) < 500;
    }

The issue is that the balance of WETH and LBR tokens in WETH/LBR Uniswap V2 can be easily manipulated by calling flash swap on the pool, which withdraws the tokens from the pool.

Example

Bob has borrowed eUSD from one of the Vaults and staked in ethlbrStakePool After some time - Alice the attacker sees that if she does a flash swap on WETH/LBR pool (removes WETH and LBR tokens from the pool), she can claim Bob's earnings by calling purchaseOtherEarnings. That is because flash swap manipulates stakedLBRLpValue value.

As a result - When Bob thought he was not in danger to withdraw his rewards, Alice took advantage of the Uniswap V2 flash swap and took Bob's rewards.

Tools Used

Manual Review

Recommended Mitigation Steps

It is not recommended to rely on Uniswap V2 pool balances, because they can be easily manipulated by calling flash swaps on them.

Assessed type

Uniswap

Lines of code

https://github.com/code-423n4/2023-06-lybra/blob/481520a1440e2637e94c1200e798841b47825a91/contracts/lybra/miner/ProtocolRewardsPool.sol#L196-L197

Vulnerability details

Impact

In ProtocolRewardsPool.getReward function, if msg.sender rewards is 2x or more than the balance of eUSD tokens in ProtocolRewardsPool, the user will not be able to get any rewards

Proof of Concept

eUSDShare value in getReward function depends on whether the contract balance is more than the user rewards amount.

            uint256 eUSDShare = balance >= reward ? reward : reward - balance;

After that eUSDShare value is used in EUSD.transferShare function to send the rewards to user

            EUSD.transferShares(msg.sender, eUSDShare);

The issue is that if the reward is twice or more than the balance, getReward function will always fail.

Example

User rewards - 1000 Contract balance - 300

This means that eUSDShare amount will be 1000 - 300 = 700 Since the contract only has 300, EUSD.transferShares(msg.sender, eUSDShare) function will fail, because the contract doesn't have enough funds even though the expected action would be to send peUSD and configurator.stableToken if there is not enough eUSD in the contract

Tools Used

Manual Review

Recommended Mitigation Steps

Change the eUSDShare line to the example below. This guarantees that the user can receive his reward even if there is not enough eUSD token.

            uint256 eUSDShare = balance >= reward ? reward : balance;

Assessed type

Token-Transfer