Caviar Private Pools - holyhansss_kr's results

Lines of code

https://github.com/code-423n4/2023-04-caviar/blob/cd8a92667bcb6657f70657183769c244d04c015c/src/Factory.sol#L71-L125 https://github.com/code-423n4/2023-04-caviar/blob/cd8a92667bcb6657f70657183769c244d04c015c/src/Factory.sol#L92

Vulnerability details

Impact

users won’t not able to create a private pool

Proof of Concept

The Factory::create() function is always exposed to the frontrunning risk. The create() function receives _salt as a parameter when creating a private pool. And since _salt is used in create2, the address is determined by _salt.

If a malicious user continues to front-run users to create a private pool with the same salt, they will not be able to create a private pool.

In addition, this vulnerability has a risk of reorg attack. you can check out this report for the reorg attack. This report is well explaining the reorg attack

Chain reorg enables creation of a pool with the same address - sashik_eth.

The reason the above attacks are possible is that the malicious user can make a pool without having an nft. Bypass can be easily done by setting tokenIds.length to 0.

Tools Used

vs code

Recommended Mitigation Steps

Do not accept salt from the user and change the salt parameter like the below code

bytes32 salt = keccak256(abi.encodePacked(msg.sender, _baseToken, _nft));
privatePool = PrivatePool(payable(privatePoolImplementation.cloneDeterministic(salt)));