QuantAMM
QuantAMM
49,600 OP
View results
Previous Next
Submission Details
Severity: low
Invalid

`UpliftOnlyExample::afterUpdate()` can be used to DOS users liquidity provisioning

0xhuntoor

Summary

in UpliftOnlyExample::addLiquidityProportional() there is a protective check to prevent more than 100 deposits, but there is a way for attacker to deposit dust positions to other users to prevent them using the protocol by first adding liquidity normally and transfer the NFT of the positions to others users, DOSing them from adding liquidity permanently by repeatedly doing it

Vulnerability Details

in UpliftOnlyExample::addLiquidityProportional() there is a check to prevent number of deposits of users to be more than 100 to protect against OOG errors during withdrawals

File: UpliftOnlyExample.sol
219: function addLiquidityProportional(
225: ) {
226: if (poolsFeeData[pool][msg.sender].length > 100) {
227: revert TooManyDeposits(pool, msg.sender);
228: }

This check can be weaponized to prevent users from interacting with the protocol, since this array can be filled by attacker by dust LP positions and then transferring the NFT position to the victims weaponizing the afterUpdate hook logic upon transfers

This is a problem since:

  • There is no minimum LP positions, allowing dust amounts

  • Any one can transfer his NFT position to any one and be registered in the to array

  • There is a check to prevent more than 100 positions

File: UpliftOnlyExample.sol
219: function addLiquidityProportional(
225: )
// attacker adding dust liquidity to him self and gettin minted NFTs
240: uint256 tokenID = lpNFT.mint(msg.sender);
​
//Attacker Mint Him self a dust NFT and transfer it
File: LPNFT.sol
49: function _update {
// Transfer the dust postion to the victim weaponzing the afterUpdate hook logic
52: if (to != address(0) && previousOwner != address(0)) {
53: //if transfering the record in the vault needs to be changed to reflect the change in ownership
54: router.afterUpdate(previousOwner, to, tokenId);
55: }
56: }
​
//afterUpdate() gets trigerred and the victim array gros in Line 614
​
File: UpliftOnlyExample.sol
//i position gets pushed to the victim array in Line 614
609: feeDataArray[tokenIdIndex].lpTokenDepositValue = lpTokenDepositValueNow;
610: feeDataArray[tokenIdIndex].blockTimestampDeposit = uint32(block.number);
611: feeDataArray[tokenIdIndex].upliftFeeBps = upliftFeeBps;
612:
613: //actual transfer not a afterTokenTransfer caused by a burn
614: poolsFeeData[poolAddress][_to].push(feeDataArray[tokenIdIndex]);
615:
616: if (tokenIdIndex != feeDataArrayLength - 1) {
618: for (uint i = tokenIdIndex + 1; i < feeDataArrayLength; i++) {
619: delete feeDataArray[i - 1];
620: feeDataArray[i - 1] = feeDataArray[i];
621: }
622: }
623:
624: delete feeDataArray[feeDataArrayLength - 1];
625: feeDataArray.pop();
626: }

The above is small concise description of the attack, this can be combined with:

  1. Frontrunning user deposits by minting 100 dust positions NFT and transferring them to the victim (on public meme Pools chains)

  2. DOS Large profile wallets or known active users using the protocol to not be able to deposit again by repeating the attack

The Above attack won't be costy since the protocol will be deployed on some L2 and will hurt the protocol and users experience
Impact

DOS Grieving of users, cause users can remove those positions if the attack is not repeated

Complete DOS of the Hook of the Pool by using malicious MEV

Tools Used

Manual review

Recommendations

make users be able to whitelist people who can transfer to them by tracking them in a mapping of normal user to array of allowed to addresses who can transfer to him

Updates

Lead Judging Commences

n0kto Lead Judge 10 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Informational or Gas / Admin is trusted / Pool creation is trusted / User mistake / Suppositions

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelyhood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.

Appeal created

0xhuntoor Submitter
10 months ago
n0kto Lead Judge
9 months ago
n0kto Lead Judge 9 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Informational or Gas / Admin is trusted / Pool creation is trusted / User mistake / Suppositions

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelyhood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.