First depositor can break minting of shares

[code423n4]

Lines of code

https://github.com/code-423n4/2022-12-caviar/blob/0212f9dc3b6a418803dbfacda0e340e059b8aae2/src/Pair.sol#L421

Vulnerability details

Impact

This is a common vulnerability. The token supply can be manipulated to prevent users from gaining a "normal" number of shares. See Section 3.4 Uniswap does this by burning the first 1000 lpTokens to significantly increase the cost of this attack.

Proof of Concept

First depositor to liquidity pool can deposit a small amount, i.e. 1 wei to mint 1 LP token. They can then donate a large number of baseToken to the protocol and make it difficult for small liquidity providers from minting any LP tokens.

baseTokenShare is calculated as baseTokenAmount * lpTokenSupply / baseTokenReserves(). Because if lpTokenSupply is 1, and if a malicious user donates 100000e18 baseToken, the next depositors need to provide at least 100000e18 baseToken to mint 1 lpToken. If user deposits say 150000e18, they will still only mint 1 lpToken due to the large rounding error.

    function addQuote(uint256 baseTokenAmount, uint256 fractionalTokenAmount) public view returns (uint256) {
        uint256 lpTokenSupply = lpToken.totalSupply();
        if (lpTokenSupply > 0) {
            // calculate amount of lp tokens as a fraction of existing reserves
            uint256 baseTokenShare = (baseTokenAmount * lpTokenSupply) / baseTokenReserves();
            uint256 fractionalTokenShare = (fractionalTokenAmount * lpTokenSupply) / fractionalTokenReserves();
            return Math.min(baseTokenShare, fractionalTokenShare);
        } else {
            // if there is no liquidity then init
            return Math.sqrt(baseTokenAmount * fractionalTokenAmount);
        }
    }

Tools Used

Manual Review

Recommended Mitigation Steps

We can do what Uniswap does, by sending the first 1000 lptoken to the 0 address when liquidity is first initiated.

[c4-judge]

berndartmueller marked the issue as duplicate of #442

[c4-judge]

berndartmueller changed the severity to 3 (High Risk)

[c4-judge]

berndartmueller marked the issue as satisfactory