Caviar contest - 0xDecorativePineapple's results

Lines of code

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

Vulnerability details

Impact

The attack vector is the same as TOB-YEARN-003, where users may not receive liquidity tokens in exchange for their baseTokenAmount and fractionalTokenAmount deposited if the total baseTokenAmount has been manipulated through a large “donation”.

In the addQuote function, the calculation of LP Tokens is as follows:

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);
        }
    

Proof of Concept

A malicious early user/first depositor of the Pair contract can deposit with wrap his/her NFT in the contract, receive 1e18 of fractional tokens in return, and then deposit the 1e18 of fractional tokens and 1e18 of baseToken to the contract. Since they are the first depositor, they will receive 1e18 of LP tokens.

Then, the attacker can send 1000e18 of baseTokens tokens to the contract, thereby inflating the price of the LP tokens. As a result, the next user who tries to add liquidity to the pool will receive 0 LP tokens, unless they set the minimum amount of LP tokens to mint. This causes the legitimate user to lose a significant portion of the amount deposited when trying to add liquidity to the pair.

Tools Used

Manual Code Review

Recommended Mitigation Steps

Uniswapv2 pair implemented the following measures to mitigate this issue:

1. Permanently locked the first MINIMUM_LIQUIDITY tokens to the zero address.
2. Added a check that the liquidity minted is at least zero