QuantAMM

Summary

The UpliftOnlyExample contract allows malicious users to add liquidity to the pools more than 100 times. As it can be seen in the code snippet below, the addLiquidityProportional function of the contract allows the sender to add liquidity to the pools. Indeed the function does check that the sender can add liquidity to the pools only limited number of time. The expectation was to limit senders up to 100 times to add liquidity to the pool. However, a feature of the contract allows malicious users to add liquidity to the pools more than 100 times. This could make the contract vulnerable to DDoS attacks. The attacker could add liquidity to the pools more than 100 times and disrupt the contract's intended functionality.

The attacker can exploit this vulnerability anytime if the attacker has knowledge of this vulnerability. Attacker only has to pay some fee (very few) at the end when the attacker removes the liquidity. This could be a potential issue and the attacker could exploit this vulnerability to disrupt the contract's intended functionality, as the attacker knows that all the added liquidity can be recovered at the end.

Vulnerability Details

The buggy issue is the tranfer of the NFT token to someone else. This feature introduces a potential vulnerability to the contract. An attacker can transfer the NFT token to another user (actually attacker will pretend to be another user) and then the attacker can add liquidity to the pool more than 100 times.

see the code snippet below:

UpliftOnlyExample.sol::addLiquidityProportional:

Above we can see atleast there's a check to limit the users to avoid adding liquidity to the pools more than 100 times or 101 times actually. But the issue is that the attacker can transfer the NFT token to another user and then the attacker can add liquidity to the pool more than 100 times.

see the code snippet below:

LPNFT.sol::_update: (an override function)

Let's say the attacker transfers the NFT token to another user, so after that above code snippet will be executed and the afterUpdate function will be called. The afterUpdate function is a public function only callable by LPNFT contract and it allows the attacker to add liquidity to the pool more than 100 times.

Above _update function override's super call has changed the ownership of the NFT. Now only records need to be updated...

see the code snippet below:

UpliftOnlyExample.sol::afterUpdate:

The afterUpdate function updates the state of the contract and gives the attacker the ability to perform a DDoS attack.

PoC

The following code snippet demonstrates how the contract could be exploited to add/transfer liquidity to the pool more than 100 times:

Steps to reproduce:

1. Go to the test folder inside pool-hooks folder then -> foundry folder -> UpliftExample.t.sol

2. Add the following test snippet just below the setUp function in the UpliftExample.t.sol file:

3. Please read the comments in the code snippet to understand the test case.

4. Now run the test cases using the following command: (Make sure you are in the pool-hooks directory)

5. As we can see in the output, the contract allows the sender to add/transfer liquidity to the pool more than 100 times.

Impact

1. The attacker can add/transfer liquidity to the pool more than 100 times.

2. The contract is vulnerable to DDoS attacks.

3. A malicious actor who has knowledge of this vulnerability could add/transfer liquidity to the pool more than 100 times and could gain the advantage of a DDoS attack.

4. Attacker can perform a DDoS attack at any time because the attacker knows that all the added liquidity can be recovered at the end. Attacker has to pay only some fee at the end when the attacker removes the liquidity, the attacker will get all the added liquidity back.

5. Vulnerability breaks the add liquidity invariant, which is:
   lim(m→100) [PFD ← l] = liquidity_added_in_the_pool

   where:
   m = multiplier (initially 1, increasing to 100)
   l = desired liquidity to add
   PFD = pool fee data
   ← represents pushing or adding liquidity

Tools Used

1. Foundry (Framework)

2. Manual Review

3. fuzz testing

Recommendations

The solution is simple and straightforward. The contract should limit the sender to add/transfer liquidity to the pools only 100 times. The following code snippet demonstrates the solution:

The above solution limits the sender to add/transfer liquidity to the pools only 100 times. Therefore, enhancing the security of the contract.