PrivatePool creation can be front-run #92
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
duplicate-419
satisfactory
satisfies C4 submission criteria; eligible for awards
Lines of code
https://github.com/code-423n4/2023-04-caviar/blob/cd8a92667bcb6657f70657183769c244d04c015c/src/Factory.sol#L71-L125
Vulnerability details
Impact
The creation of a PrivatePool using the
Factory
contract's create method can be front-run by anyone.This is a simple griefing attack with no funds at immediate risk if the user who wanted to create the pool notices that the transaction has failed.
If the user fails to recognize the failed transaction and proceeds to deposit funds into the PrivatePool, which was created by the front-runner but the user believes it's his, the funds can be withdrawn only by the front-runner.
So, best-case of this vulnerability is griefing (gas loss for user) and worst-case is loss of funds.
Proof of Concept
The following PoC demonstrates the front-running of a PrivatePool creation with a subsequent deposit of ETH and NFTs by the "orignial" creator. Later on, these funds are withdrawn/stolen from the pool by the front-runner.
First, fix the
setUp
method intest/Factory/Create.t.sol
by moving the linefactory = new Factory();
above the construction of thePrivatePool
implementation contract. This ensures that the pool ownership checking works correctly.Second, add the follwing test case to
test/Factory/Create.t.sol
and run it:Log:
Tools Used
VS Code, Foundry
Recommended Mitigation Steps
Incorporate the
msg.sender
into the contract creation salt, e.g.bytes32 newSalt = keccak256(abi.encodePacked(salt, msg.sender));
and use it in thecreate
andpredictPoolDeploymentAddress
methods of theFactory
contract.This way, an attacker cannot create a PrivatePool at the same address as another user.
The text was updated successfully, but these errors were encountered: