Summary

CREATE2 address collision against an Account will allow complete draining of auction tokens

Vulnerability Details

The attack consists of two parts: Finding a collision, and actually draining the auction tokens. address auctionToken,
uint256 biddingTime,
uint256 totalTokens,
bytes32 salt can all be generated.

The address collision an attacker will need to find are:

• One undeployed auction account address (1).

• Arbitrary attacker-controlled wallet contract (2).

Both sets of addresses can be brute-force searched because:

• The salt is a user-supplied parameter. By brute-forcing many salt values, we can obtain many different (undeployed) wallet accounts for (1).

• (2) can be searched the same way. The contract just has to be deployed using CREATE2, and the salt is in the attacker's control by definition.

An attacker can find any single address collision between (1) and (2) with high probability of success using the following meet-in-the-middle technique, a classic brute-force-based attack in cryptography:

• Brute-force a sufficient number of values of salt (2^80), pre-compute the resulting account addresses, and efficiently store them e.g. in a Bloom filter data structure.

• Brute-force contract pre-computation to find a collision with any address within the stored set in step 1.

The feasibility, as well as detailed technique and hardware requirements of finding a collision, are sufficiently described in multiple references:
1: A past issue on Sherlock describing this attack.

• 2: EIP-3607, which rationale is this exact attack. The EIP is in final state.

• 3: A blog post discussing the cost (money and time) of this exact attack.

inspiration: https://github.com/sherlock-audit/2023-12-arcadia-judging/issues/59

Impact

Loss of all tokens

Tools Used

Manual review

Recommendations

• Don't allow the user to control the salt used.

• Consider also adding and encoding block.timestamp and block.number combined with the user's salt.