Fjord Token Staking

Summary

The createAuction function within the factory contract utilizes the CREATE2 opcode to deploy new auction contracts with a deterministic address based on a user-supplied salt. This exposes the function to a potential address collision attack, where an attacker could precompute a contract address that matches a yet-to-be-deployed auction contract. If successful, the attacker could deploy their malicious contract at the same address, allowing them to intercept the transfer of auction tokens. This would result in the complete draining of tokens intended for the auction.

Vulnerability Details

The vulnerability in the createAuction function stems from the use of the CREATE2 opcode, which allows the deployment of contracts at deterministic addresses based on a user-supplied salt. This creates an opportunity for an attacker to find an address collision, enabling them to deploy a malicious contract at the same address as the intended auction contract. The attack involves two stages: finding the collision and draining the auction tokens.

In the createAuction function, the contract is created using CREATE2 with a salt provided by the user:

An attacker could perform a brute-force search to find a collision between:

1. The undeployed auction contract address.

2. An attacker-controlled contract address.

since the salt is provided by the function caller, the attacker can compute a large number of potential contract addresses. By precomputing a set of undeployed auction contract addresses and attacker-controlled contract addresses, the attacker can use a meet-in-the-middle attack, a well-known cryptographic technique, to identify a collision with high probability.

Once a transaction that creates an auction with a precomputed salt is present in the mempool, the attacker can deploy their malicious contract at the collided address. The following steps illustrate how the auction tokens could then be drained:

First Transaction:

1. The attacker deploys their malicious contract at the collided address using the identified salt.

2. The malicious contract automatically sets an allowance for the attacker’s wallet, allowing it to transfer the auction tokens.

Second Transaction:

1. The legitimate createAuction function is mined, deploying the intended auction contract at the collided address.

2. The tokens meant for the auction are transferred to the collided address, which now has an approval for the attacker's wallet.

3. The attacker uses the previously set allowance to transfer the auction tokens to their own wallet.

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

Impact

Complete draining of auction tokens if an address collision is found.

Tools Used

Manual Review

Recommendations

Avoid using CREATE2 for contract deployment and instead utilize the standard contract creation method with CREATE. When using CREATE, the contract’s address is derived from the msg.sender (which is the factory contract in this case) and the factory’s internal nonce.