Potential security implications of CREATE2? (EIP-1014)

EIPs
,
11
  • Regarding the fact that CREATE2 ->A, CREATE -> B+2 x SELFDESTRUCT and then CREATE2 -> Amod, CREATE -> Bmod

I don’t think that changes things a lot. It simply further an argument against an anti-pattern: the anti-pattern of trying to establish trust through investigating history of a contract.

The pattern that should be used, is:

  • Use EXTCODEHASH to verify that the code you are calling matches what you expect. This might mean that during either compilation, construction or initialization (not necessarily same as construction), you store the expected EXTCODEHASH for other contracts that you will interact with.
    • Example: A DEX, when enrolling new ERC20 assets, may have to store the EXTCODEHASH when the new asset is enrolled.
      • Bonus: When solidity does a call, today it uses EXTCODESIZE to verify that the contract exists. It could use EXTCODEHASH instead, and internalize it so the call would look maybe like theToken.verify(codehash).transfer(from, to, value).
      • Alternative: when enrolling the token, it would do a safety-check, to verify once and for all that the contract is immutable.
    • There may arise an immutability-registry. That would simply run a check that contract X does not have SELFDESTRUCT, DELEGATECALL, CALLCODE (that’s it right?). EDIT TO CLARIFY: A registry of codehashes, not addresses.

That was the on-chain scenario, so how about the EOA scenario, interacting with a contract Casino?

  • Attack vector: When user sends large amount of ether to Casino, then the operator front-runs with two transactions:

    1. SELFDESTRUCT Casino.
    2. CREATE2 a new Casino which steals the funds.

OBS: The SELFDESTRUCT and recreation cannot happen within one transaction, due to how SELFDESTRUCT operates.

This scenario is flawed from the beginning:

  1. The EOA should not send money to a contract which can SELFDESTRUCT without prior notice. That’s dangerous even today (but there is no payout for the operator, only the wreak-havoc factor).
  2. If the user, despite this, wants to interact with the contract, he can do so e.g. via a personal on-chain wallet.

At the end of the day, auditors and developers NEED to get up to speed with these new changes. It’s been discussed ever since the suggestion of the first CREATE2 variant, and then further discussed with the current variant.

3 Likes