Venus Protocol Isolated Pools - Norah's results

Lines of code

https://github.com/code-423n4/2023-05-venus/blob/main/contracts/VToken.sol#L180-L185 https://github.com/code-423n4/2023-05-venus/blob/main/contracts/VToken.sol#L743-L791 https://github.com/code-423n4/2023-05-venus/blob/main/contracts/VToken.sol#L743-L791 https://github.com/code-423n4/2023-05-venus/blob/main/contracts/VToken.sol#L1463-L1483 https://github.com/code-423n4/2023-05-venus/blob/main/contracts/VToken.sol#L1476 https://github.com/code-423n4/2023-05-venus/blob/main/contracts/VToken.sol#L1421-L1424

Vulnerability details

Impact

Attacker can steal funds from normal user under certain condition.

Proof of Concept

Consider following scenario :

When totalSupply = 0,

• Attacker deposits few underlying to mint themself 1 vTOken, they basically own 100% share of the pool with this 1 vToken.

• Now Attacker supplies huge amount of underlying tokens to the vToken contract indirectly(with ERC20 transfer, not via mint function).

• Any, subsequent normal users trying to mint vToken by depositing the underlying won't be minted any share as amount of token to be minted is calculated as mintAmount/exchangeRate, and ExchangeRate is calculated via underlying.balanceOf(address(this)), which has been artificially increased as mentioned in previous step, so the result will be zero for most users. so users underlying will be transfer to contract but they will be zero share.

• Now after some such transaction, attacker withdraws their and pools only 1 vToken, claiming entire amount of underlying asset own by pool, (which includes their indirect supply as well as victim users funds).

This is pretty common issue in protocol related to lending/borrowing protocol.

Tools Used

Manual Review

Recommended Mitigation Steps

Best solution as the protocol is not deployed yet is to burn few shares as soon as first shares are minted, alternatively you can manually few shares to ensure totalsupply never goes to zero.

Assessed type

Other