First depositor can break miting of shares

[code423n4]

Lines of code

https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Vault/contracts/ReaperVaultV2.sol#L334

Vulnerability details

Impact

The attack vector and impact is the same as TOB-YEARN-003 , where users may not receive shares in exchange for their deposits if the total asset amount has been manipulated through a large “donation”.

This issue in deposit function, the amount of the minted shares can round down to zero.

Proof of Concept

A malicious early user / first depositor of the Vault can deposit with 1 wei of the asset token and then get 1 wei of shares token.

Then the malicious attacker can send 10000e18 amount of asset tokens and inflate the price from 1.000 to the extreme value of 1.0000e22

As a result, the next users who deposit 199999e18 wei will only receive 1 wei of shares in shares = (_amount * totalSupply()) / freeFunds.

So, the legitimate user will lose 9999e18 after their deposit.

This is a common risk of Empty ERC4626 Vaults, due to rounding in favor of the vault. The attack can also be performed as a frontrunning attack.

https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Vault/contracts/ReaperVaultV2.sol#L334

    function _deposit(uint256 _amount, address _receiver) internal nonReentrant returns (uint256 shares) {
        _atLeastRole(DEPOSITOR);
        require(!emergencyShutdown, "Cannot deposit during emergency shutdown");
        require(_amount != 0, "Invalid amount");
        uint256 pool = balance();
        require(pool + _amount <= tvlCap, "Vault is full");

        uint256 freeFunds = _freeFunds();
        uint256 balBefore = token.balanceOf(address(this));
        token.safeTransferFrom(msg.sender, address(this), _amount);
        uint256 balAfter = token.balanceOf(address(this));
        _amount = balAfter - balBefore;
        if (totalSupply() == 0) {
            shares = _amount;
        } else {
            shares = (_amount * totalSupply()) / freeFunds; // use "freeFunds" instead of "pool" //@audit first deposit issue
        }

Tools Used

Manual

Recommended Mitigation Steps

In Uniswap V2 solved this problem by sending the first 1000 LP tokens to the zero address. The same can be done in this case i.e. when totalSupply() == 0, send the first min liquidity LP tokens to the zero address to enable share dilution.

Also, it is advised to monitor the Openzeppelin Discussion and Solmate Discussion for possible mitigation to the issue.

[c4-judge]

trust1995 changed the severity to 2 (Med Risk)

[c4-judge]

trust1995 marked the issue as satisfactory

[c4-judge]

trust1995 marked the issue as duplicate of #848

[c4-judge]

trust1995 changed the severity to QA (Quality Assurance)