Fjord Token Staking

## Summary

https://github.com/Cyfrin/2024-08-fjord/blob/0312fa9dca29fa7ed9fc432fdcd05545b736575d/src/FjordAuctionFactory.sol#L52

The factory function FjordAuctionFactory::createAuction() creates a new auction contract using CREATE2. A very similar vulnerability is elaborated here in length => https://solodit.xyz/issues/m-2-create2-address-collision-against-an-account-will-allow-complete-draining-of-lending-pools-sherlock-arcadia-git

The above vulnerability shows that a meet-in-the-middle attack at finding an address collision against an undeployed account is possible. Furthermore, such an attack allows draining of all tokens and fjord points from the auction.

Another hot discussion on the same topic can be found here => https://github.com/sherlock-audit/2024-06-makerdao-endgame-judging/issues/64

Function in question:

## Vulnerability Details

We know that meet-in-the-middle attack is possible. If an attacker finds an address collision against an undeployed account, he can drain all tokens and fjord points from the auction.

The attack would be as such:

- The attacker knows the collided address and deploys the attack contract onto `0xCOLLIDED`

- Sets infinite allowance for themselves for auction token and fjord points contract

- Destroy the contract using selfdestruct.

Post Dencun hardfork, selfdestruct is still possible if the contract was created in the same transaction. The only catch is that all 3 of these steps must be done in one tx.

Now when the real auction contract gets deployed, the attacker will have control of the funds. They can drain everything from the go.

## Impact

Complete draining of auction tokens and points.

## Tools Used

Manual review

## Recommended Mitigation

The mitigation method is to prevent controlling over the deployed account address (or at least severely limit that). Some techniques may be:

Do not allow a user-supplied salt, as well as do not use the user address as a determining factor for the salt.

Use the vanilla contract creation with CREATE, as opposed to CREATE2. The contract's address is determined by msg.sender (the factory), and the internal nonce of the factory (for a contract, this is just "how many other contracts it has deployed" plus one).

This will prevent brute-forcing of one side of the collision, disabling the $O(2^{81})$ search technique.