Venus Protocol Isolated Pools - Cryptor's results

Lines of code

https://github.com/code-423n4/2023-05-venus/blob/8be784ed9752b80e6f1b8b781e2e6251748d0d7e/contracts/VToken.sol#L1272-L1279 https://github.com/code-423n4/2023-05-venus/blob/8be784ed9752b80e6f1b8b781e2e6251748d0d7e/contracts/VToken.sol#L769-L776

Vulnerability details

Impact

Users are vulnerable to an inflation attack where a user can lose funds due to a malicious actor directly depositing funds into the vToken contract.

Proof of Concept

The function _Mintfresh calls the function DoTransferIn which calculates the amount of vTokens to mint to a user after supplying the underlying asset. DotransferIn calculates the balance of the underlying asset in the contract as follows:

  function _doTransferIn(address from, uint256 amount) internal virtual returns (uint256) {
        IERC20Upgradeable token = IERC20Upgradeable(underlying);
        uint256 balanceBefore = token.balanceOf(address(this));
        token.safeTransferFrom(from, address(this), amount);
        uint256 balanceAfter = token.balanceOf(address(this));
        // Return the amount that was *actually* transferred
        return balanceAfter - balanceBefore;
    }

https://github.com/code-423n4/2023-05-venus/blob/8be784ed9752b80e6f1b8b781e2e6251748d0d7e/contracts/VToken.sol#L1272-L1279

The vulnerability here is that a malicious can directly send the underlying assets directly to the contract, affecting the number of Vtokens minted to an unsuspecting user. This can be used in a MEV sandwich attack where a user can have their funds stolen by front running a user calling the function mint with a direct transfer, calling mint and then withdrawing the tokens

Tools Used

Manual Review

Recommended Mitigation Steps

Use a mapping instead of BalanceOf, to track the balance of underlying assets

Assessed type

MEV