Lybra Finance - devival's results

Lines of code

https://github.com/code-423n4/2023-06-lybra/blob/7b73ef2fbb542b569e182d9abf79be643ca883ee/contracts/lybra/governance/LybraGovernance.sol#L120-L122

Vulnerability details

Impact

Detailed description of the impact of this finding.

Even though, the votes are calculated correctly, the proposals view function returns wrong voting results returning forVotes results as againstVotes amount.

This would negatively impact the users understanding of the proposals voting results and lead to confusions.

Proof of Concept

Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept.

The Governance COUNTING_MODE() is set Bravo as follows:

    function COUNTING_MODE() public override view virtual returns (string memory){
          return "support=bravo&quorum=for,abstain";
    }

LybraGovernance.sol#L156

This refers to the vote options 0 = Against, 1 = For, 2 = Abstain, as in GovernorBravo. Openzepping#Governor,

The total amount of votes are stored in proposalData[proposalId].supportVotes[X], where X, as abovementioned, can be 0 = Against, 1 = For, 2 = Abstain:

    struct ProposalExtraData {
        mapping(address => Receipt)  receipts;
        mapping(uint8 => uint256) supportVotes;
        uint256 totalVotes;
    }

    mapping (uint256 => ProposalExtraData) public proposalData;

LybraGovernance.sol#L27

Finally, this is the proposals function which returns forVotes as a total amount of votes against, which corresponds to proposalData[proposalId].supportVotes[0]:

    function proposals(uint256 proposalId) external view returns (uint256 id, address proposer, uint256 eta, uint256 startBlock, uint256 endBlock, uint256 forVotes, uint256 againstVotes, uint256 abstainVotes, bool canceled, bool executed) {
        id = proposalId;
        //...
        
        forVotes =  proposalData[proposalId].supportVotes[0];
        againstVotes =  proposalData[proposalId].supportVotes[1];
        abstainVotes =  proposalData[proposalId].supportVotes[2];
        //...
    }

LybraGovernance.sol#L120-L122

Tools Used

Manual Review

Recommended Mitigation Steps

In LybraGovernance.sol#L120-L122 replace

        forVotes =  proposalData[proposalId].supportVotes[0];
        againstVotes =  proposalData[proposalId].supportVotes[1];

with

        againstVotes =  proposalData[proposalId].supportVotes[0];
        forVotes =  proposalData[proposalId].supportVotes[1];

Assessed type

Other

Lines of code

https://github.com/code-423n4/2023-06-lybra/blob/7b73ef2fbb542b569e182d9abf79be643ca883ee/contracts/lybra/governance/LybraGovernance.sol#L172-L174

Vulnerability details

Impact

The proposal can be created with only 100_000 esLBR delegated instead of 10_000_000.

Proof of Concept

According to LybraV2Docs, a proposal can only be created if the sender has at least 10 million esLBR tokens delegated to his address to meet the proposal threshold.

In LybraGovernance.sol#L172-L174 the proposal threshold is set to only 1e23 which equals to 100_000 as esLBR has 18 decimals.

    function proposalThreshold() public pure override returns (uint256) {
        return 1e23;
    }

LybraGovernance.sol#L172-L174

Tools Used

Manual Review

Recommended Mitigation Steps

In LybraGovernance.sol#L173 replace 1e23 with 1e25

Alternatively, the team can update the documentation stating that it is only required 100_000 esLBR tokens (0.1% of the total LBR supply) delegated to meet the proposal threshold.

Assessed type

Math

Lines of code

https://github.com/code-423n4/2023-06-lybra/blob/7b73ef2fbb542b569e182d9abf79be643ca883ee/contracts/lybra/governance/LybraGovernance.sol#L143-L145

Vulnerability details

Impact

LybraGovernance contract only allows to vote during the first 3 blocks after the snapshot is taken. Assuming it takes roughly 12 seconds per 1 block on Ethereum, it is only 36 seconds to decide and vote for a proposal.

This would be too fast for a regular human being to evaluate the proposal and vote.

Proof of Concept

In LybraGovernance.sol, the clock() implements block number as a unit of time:

    function clock() public override view returns (uint48){
        return SafeCast.toUint48(block.number);
    }

LybraGovernance.sol#L161-L163 Openzeppelin#votingPeriod

According to the Lybra V2 Docs: "When a proposal is created, the community can cast their votes during a 7 day voting period. "

However, instead of 7 days, the current voting period has hardcoded 3 blocks:

    function votingPeriod() public pure override returns (uint256){
         return 3;
    }

LybraGovernance.sol#L147-L149 not allowing users enough time to evaluate the proposal and vote making the whole Governor contract useless.

Tools Used

Manual Review

Recommended Mitigation Steps

Set the votingPeriod() to return 50400 blocks (604800 seconds in a day divided by 12 seconds (Approx. Ethereum Average Block Time) LybraGovernance.sol#L147-L149

Alternatively, change the unit of time to block.timestamp and set votingPeriod to 7 days, if it is intended to be used in different blockchain, due to the different time it takes for each block to be mined.

Assessed type

Timing

Lines of code

https://github.com/code-423n4/2023-06-lybra/blob/7b73ef2fbb542b569e182d9abf79be643ca883ee/contracts/lybra/governance/LybraGovernance.sol#L147-L149

Vulnerability details

Impact

Detailed description of the impact of this finding.

With a voting delay set to 1 block, users would not have enough time to buy tokens, or delegate their votes.

Proof of Concept

Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept.

In LybraGovernance.sol, the clock() implements block number as a unit of time:

    function clock() public override view returns (uint48){
        return SafeCast.toUint48(block.number);
    }

LybraGovernance.sol#L161-L163

This means, if votingDelay function returns 1, the delay since the proposal is submitted until voting power is fixed and voting starts equals 1 block. Openzeppelin#votingDelay

Tools Used

Manual Review

Recommended Mitigation Steps

Set votingDelay to at least 7200 blocks (~1 day) Ethereum Average Block Time)

Assessed type

Timing

Lines of code

https://github.com/code-423n4/2023-06-lybra/blob/7b73ef2fbb542b569e182d9abf79be643ca883ee/contracts/lybra/configuration/LybraConfigurator.sol#L339 https://github.com/code-423n4/2023-06-lybra/blob/7b73ef2fbb542b569e182d9abf79be643ca883ee/contracts/lybra/pools/base/LybraPeUSDVaultBase.sol#L128

Vulnerability details

Impact

The liquidation function in all contracts inheriting LybraPeUSDVaultBase.sol would revert until both vaultSafeCollateralRatio[pool] and vaultBadCollateralRatio[pool] are set. Even though, according to the documentation, the default safe and bad collateral ratios should be 160 and 150 respectively.

Contracts affected by LybraPeUSDVaultBase abstract: LybraWbETHVault.sol, LybraWstETHVault.sol, LybraRETHVault.sol.

Proof of Concept

In getBadCollateralRatio function in LybraConfigurator.sol, if vaultBadCollateralRatio[pool] equals 0, the function would return vaultSafeCollateralRatio[pool] - 1e19.

    function getBadCollateralRatio(address pool) external view returns(uint256) {
        if(vaultBadCollateralRatio[pool] == 0) return vaultSafeCollateralRatio[pool] - 1e19;
        return vaultBadCollateralRatio[pool];
    }

However, if vaultSafeCollateralRatio[pool] is not manually set through setSafeCollateralRatio function, it will equal 0, which will make vaultSafeCollateralRatio[pool] - 1e19 cause a revert due to the possible underflow.

LybraConfigurator.sol#L339

As a consequence, liquidation function in all contracts inheriting LybraPeUSDVaultBase.sol would revert after calling getBadCollateralRatio.

LybraPeUSDVaultBase.sol#L128

Tools Used

Manual Review

Recommended Mitigation Steps

Replace vaultSafeCollateralRatio[pool] - 1e19 with 150 * 1e18 in getBadCollateralRatio function of LybraConfigurator.sol. LybraConfigurator.sol#L339

Assessed type

Under/Overflow

Lines of code

https://github.com/code-423n4/2023-06-lybra/blob/7b73ef2fbb542b569e182d9abf79be643ca883ee/contracts/lybra/pools/LybraWbETHVault.sol#L10

Vulnerability details

Impact

Detailed description of the impact of this finding.

Executing getAssetPrice() will always fail which makes all functions calling it fail as well. This includes depositEtherToMint which will not allow to deposit any funds to the contract.

Proof of Concept

Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept.

In depositEtherToMint of LybraWBETHVault.sol and LybraRETHVault.solthere is the line of code calling getAssetPrice():

        _mintPeUSD(msg.sender, msg.sender, mintAmount, getAssetPrice());

LybraWbETHVault.sol#L28 LybraRETHVault.sol#L35 getAssetPrice() function calls nonexistent function exchangeRatio() in WBETH contract to get the exchange rate of WBETH. This will make the call to always fail.

   function getAssetPrice() public override returns (uint256) {
        return (_etherPrice() * IWBETH(address(collateralAsset)).exchangeRatio()) / 1e18;
    }

LybraWbETHVault.sol#L35

Tools Used

Manual Review

Recommended Mitigation Steps

Replace exchangeRatio() with exchangeRate() in the following instances: IWBETH interface LybraWbETHVault.sol#L10

getAssetPrice() function LybraWbETHVault.sol#L35

IRETH interface LybraRETHVault.sol#L10

getAssetPrice() function in LybraRETHVault.sol#L47

Assessed type

Error

Lines of code

https://github.com/code-423n4/2023-06-lybra/blob/7b73ef2fbb542b569e182d9abf79be643ca883ee/contracts/lybra/pools/LybraWbETHVault.sol#L16

Vulnerability details

Impact

According to the developer’s comment in LybraWbETHVault.sol, the WBETH contract address is intended to be 0xae78736Cd615f374D3085123A210448E74Fc6393, which is rETH Token address. In case rETH Token address is passed in the LybraWbETHVault.sol constructor the contract will not be functional.

Proof of Concept

IWBETH interface has a deposit function function deposit(address referral) external payable; While there is no deposit function in rETH.

Tools Used

Manual Review

Recommended Mitigation Steps

Use the correct WBETH Token address 0xa2E3356610840701BDf5611a53974510Ae27E2e1

Assessed type

Other