Attacker can frontrun creator of project to deny admin ownership

[c4-bot-8]

Lines of code

https://github.com/code-423n4/2024-06-vultisig/blob/cb72b1e9053c02a58d874ff376359a83dc3f0742/src/ILOManager.sol#L57

Vulnerability details

Summary

Context: Function initProject() allows anyone to create a project by passing InitProjectParams.

Issue: The issue is that an attacker can frontrun the project creator by submitting the same InitProjectParams parameters. This would give him the admin ownership of the project as seen here.

Proof of Concept

1. Original creator calls function initProject() to create a new project.

2. The attacker calls the same function with the same parameters and pays gas at a higher gas price to frontrun the creator.

3. Once the attacker's call executes first, the project is cached permanently with the admin being the attacker.

File: ILOManager.sol
148:         _project.admin = msg.sender;

4. The original creator's call reverts due to this check on Line 144 in the function _cacheProject().

File: ILOManager.sol
133: 
134:     function _cacheProject(
135:         address uniV3PoolAddress,
136:         address saleToken,
137:         address raiseToken,
138:         uint24 fee,
139:         uint160 initialPoolPriceX96,
140:         uint64 launchTime,
141:         uint64 refundDeadline
142:     ) internal {
143:         Project storage _project = _cachedProject[uniV3PoolAddress];
144:         require(_project.uniV3PoolAddress == address(0), "RE");

5. The attacker could negotiate transferring the admin ownership since there is a function transferAdminProject() to do so. This would be a likely scenario so the impact of this could be escalated depending on the situation.

Tools Used

Manual Review

Recommended Mitigation Steps

Currently there is no direct mitigation to this since any transaction could be frontrun. The only solution is to introduce a registration mechanism where the owner can create the project for the respective team. I'd recommend exploring more solutions to this (if any).

Assessed type

DoS

[mcgrathcoutinho]

Hey @alex-ppg, keeping these issue in loop with supporting comments provided by warden in issue #106

[alex-ppg]

Hey @mcgrathcoutinho, thank you for the PJQA contribution. I will preface all validation repository finding responses by stating that they are not evaluated by judges directly and are only evaluated by the validators if they are deemed unsatisfactory.

The same rationale as laid out in #106 applies here.

This paragraph is included in all of my responses and confirms that no further feedback is expected in this submission as PJQA has concluded. You are free to refute any of my statements factually, however, I strongly implore you to do this with actual code references and examples.