Fjord Token Staking

Summary

A replay attack on another chain leverages the predictability of salt generation in create2 to duplicate or block contract deployments across different blockchains or forks. This leaves the contract vulnerable to cross-chain exploitation.

Vulnerability Details

Replay Attack on Another

1. Context:

• Multi-Chain Deployment: Suppose the FjordAuctionFactory contract is deployed on multiple blockchains or forks. The deployment script uses create2 with a salt based on block.timestamp and msg.sender.

• Identical salt Generation: In the event that the same deployment script is used across these chains without modification, and if the block.timestamp and msg.sender are identical (or sufficiently similar) across chains, the same salt will be generated on each chain.

• Deterministic Address Generation: Since create2 generates a deterministic contract address based on the salt, the same contract address will be calculated on each chain.

2. Execution Steps of a Replay Attack on Another Chain:

1. Initial Deployment on Chain A:

   • A user or entity (let's call them Alice) runs the auction deployment script on Chain A.

   • The script generates a salt based on the block.timestamp and msg.sender on Chain A, let's say the salt is 0xabc123.

   • The create2 function uses this salt to deploy an auction contract at a specific address on Chain A.

2. Deployment on Chain B:

   • Later, the same deployment script is run on Chain B (which could be a different blockchain or a fork of Chain A).

   • If the block.timestamp and msg.sender are similar or the same on Chain B, the script will generate the same salt (0xabc123) as on Chain A.

   • The create2 function on Chain B calculates the same deterministic address and attempts to deploy a new auction contract at that address.

3. Replay Attack Scenario:

   • Case 1: Contract Already Exists on Chain B: If an auction contract has already been deployed on Chain B (possibly due to a previous or identical replay attack), the deployment on Chain B will fail, as the address is already occupied.

   • Case 2: No Contract Exists on Chain B: If no contract exists at the address on Chain B, the script will successfully deploy the contract. However, this could lead to an unintended or duplicate auction being created on Chain B, confusing users and possibly leading to financial losses.

4. Malicious Replay:

   • An attacker who is aware of the deployment on Chain A could intentionally replay the transaction on Chain B, knowing that the same salt will generate the same address. This could lead to:

     • DoS Attack on Chain B: The attacker could pre-deploy a contract on Chain B at the predicted address, preventing the legitimate deployment.

     • Confusion and Exploitation: If the auction is successfully replayed on Chain B, users might be confused about which auction is legitimate, potentially leading to double spending or other financial losses.

Impact

• DoS Attack on Chain B: The attacker could pre-deploy a contract on Chain B at the predicted address, preventing the legitimate deployment.

• Confusion and Exploitation: If the auction is successfully replayed on Chain B, users might be confused about which auction is legitimate, potentially leading to double spending or other financial losses.

Tools Used

Manual Review

Recommendations

• Chain-Specific Salt Generation:

  • Incorporate a chain-specific identifier (like block.chainid) into the salt calculation to ensure that the same transaction does not generate the same salt across different chains.

  • Example:

    ​

    `bytes32 salt = keccak256(abi.encodePacked(block.timestamp, msg.sender, block.chainid));`

  • This ensures that the salt is unique for each chain, preventing a replay attack from creating the same contract address on different chains.

• Replay Protection Measures:

  • Deploy contracts with replay protection mechanisms, such as nonce-based or multi-signature checks, to prevent identical transactions from being replayed across chains.