Read the findings of the 2022 Web3 Security Report

`LendingPool` and `LidoVault` are versioned upgradable contracts. The contract owner can upgrade the contract without the community's commitment. If an attacker compromises the account, he can change the implementation of the contract and drain tokens from the contract.


Centralized Control of Contract Upgrade

`_vaultFee` Not Capped

In the contract `LendingPool`, the role `LendingPoolConfigurator` has the authority over the following function:
- registerVault
- initReserve
- setReserveInterestRateStrategyAddress
- setConfiguration
- setPause

Any compromise to the `LendingPoolConfigurator` account may allow the hacker to take advantage of this and cause assets lost.

Centralization Risk

In the `LendingPool` contract, stable coin holders can deposit their stable coins to earn interests, and `LidoVault` users deposit their ETH/LIDO as collateral to borrow stable coins. But the yields distributed from `LidoVault` don't match the interests paid for stable coin holders. 

Functions `reserve.updateState()` and `reserve.updateInterestRates()` are called in function `swapBorrowRateMode` and `rebalanceStableBorrowRate`, that affect interest rates.

Issue update:
Assume the amount of deposited collateral asset(`LIDO`) and stable token(`USDT`) are fixed, no one borrows stable tokens from the `lendingPool`, yields distributed is fixed, when 90% of stable tokens are borrowed, yields distributed do not change, but interest rate increased. Is our assumption reasonable?


Design Issue

In function `initReserve`, it initializes a reserve and actives it, there is no underlaying asset deposited, so `aTokenAddress.totalSupply()` should be zero.

`aTokenAddress.totalSupply()`  Should Be Zero

`aTokenAddress` should be `variableDebtAddress` in comments.

typo

In function `_convertAssetByCurve`, it calls `ICurveSwap(CurveswapLidoPool).get_dy` to get `minAmount`, which is always the same as  `receivedAmount` returned from `ICurveSwap(CurveswapLidoPool).exchange(1, 0, _fromAmount, minAmount)`, so it can not prevent the Sandwich Attack, if `CurveswapLidoPool` can be Sandwich Attacked.

The right way to get `minAmount` is to pass it from outside of this transaction.


Invalid `minAmount`

A sandwich attack might happen when an attacker observes a transaction swapping tokens or adding liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (before the transaction being attacked) a transaction to purchase one of the assets and make profits by backrunning (after the transaction being attacked) a transaction to sell the asset.

The following functions are called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large:

- `_convertAssetByCurve()`


Potential Sandwich Attacks

Use of strict equalities that can be easily manipulated by an attacker, for example, attacker can transfer a fewer amount of tokens to the contract and cause `processYield` fail all times.



Dangerous Strict Equalities

The contract is serving as the underlying entity to interact with third party `LIDO` protocols. The scope of the audit treats 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.

Third Party Dependencies

Sturdy

GeneralVault.sol

LidoVault.sol

Sturdy

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

10

0

2

2

6