CertiK is proud to present the CREATE2 Audit Tool, the first easy-to-use resource for smart contract developers to identify whether their program is resistant to vulnerabilities simply by entering the address of their smart contract on our website. But before we get into why this will be beneficial to the blockchain community, we should explain:

What is CREATE2?

CREATE2 was first introduced as an upgrade to the Ethereum network following the Constantinople hard fork in February 2019. While CREATE2 provides users with exciting benefits that increase scalability and improve the user onboarding process, the new instruction requires Ethereum users to perform extra audits to ensure that a smart contract is safe to interact with.

The introduction of CREATE2 now allows the possibility for code to be maliciously altered even after it’s been deployed. A smart contract’s code is susceptible to CREATE2 manipulations if:

1. it contains a SELFDESTRUCT or DELEGATECALL opcode, AND
2. it’s developed with CREATE2, or created by a contract that was created with CREATE2, or a contract created by a contract that was created with CREATE2, and so forth.

Essentially, any contract in a "chain" of creation that has a SELFDESTRUCT or DELEGATECALL opcode may be vulnerable.

Why Is It Vulnerable?

Let’s imagine a scenario to demonstrate— John wants to be malicious and decides to deploy a contract using CREATE2. Alice audits the code and believes that the contract is safe, so she sends it some Ether. However, Alice doesn’t realize that John can replace the code with CREATE2 and call a SELFDESTRUCT function which he set up to forward funds into an external address after the account is destroyed. Once Alice’s transaction is accepted by the network, John calls the SELFDESTRUCT function, he gets the funds in his account, and Alice is left with no contract and lost funds.

Yes, it’s that easy! Unlike the CREATE opcode that does not allow for contract alteration, CREATE2 has serious security implications.

One of CREATE2’s key features allows for a contract’s address to be determined prior to its creation. Let’s go into more detail on why CREATE2 makes contracts susceptible to malicious code alterations:

• If an account is created by an Ethereum wallet or by the standard CREATE opcode, its address is determined by:
  • hashing the address of the account that created it
  • hashing the 'account nonce,' which is equivalent to the number of transactions completed by the account so far.
• In contrast, with CREATE2, the address will be determined by:
  • hashing the address of the account that created it
  • hashing an arbitrary salt
  • hashing the ‘initcode’ for the contract
  • Note: the ‘initcode’ is a bytecode for a function that returns the code of the new contract as its output. It contains constructor logic as well as the code for the contract.

Therefore, if a contract is deployed by CREATE2 and then self-destructed, the same account that created it can redeploy it with altered code using the same address, like the example shown above.

While the 'initcode' must be the same, it can also be non-deterministic — meaning it can read variables from state. Subsequently, even with the same 'initcode', it is possible for the actual contract code to be different once it is redeployed

Under the Radar

Another vulnerability that’s more difficult to detect is when a contract is created by a CREATE2-type contract. The reason behind this is that when a contract is self-destructed, its ‘account nonce’ is reset.

For instance, imagine Contract A creates Contract B with CREATE2, and then Contract B creates Contract C using the standard CREATE opcode. Then if we destroy both Contract B and C, we can then create Contract B and C again using the same addresses as before.

In other words, Contract B can be recreated with CREATE2, and Contract C can be recreated with the same addresses since the same ‘account nonce’ can be reutilized.

In consequence, the code of the recreated Contract B and C can be completely different from the initial code. Hence, it is essential that there are measures in place that can be utilized by smart contract developers to combat the potential inclusion of malicious code for even a live smart contract.

On February 15, 2019, during the 55th Ethereum Core Devs meeting, the team concluded that the identified risks of CREATE2 can be mitigated through proper audit of codes.

Aligned with CertiK’s commitment to continuing to improve security within the blockchain ecosystem, we welcome all smart contract developers to use our CREATE2 Auditing Tool to ensure that their contracts are resistant to malicious alterations.

Test the security of your smart contract using our CREATE2 Audit Tool

About CertiK

CertiK leads blockchain security by pioneering the use of cutting-edge Formal Verification technology on smart contracts and blockchains. Unlike traditional security audits, Formal Verification mathematically proves program correctness and hacker-resistance. CertiK was founded by Computer Science professors of Yale University and Columbia University, securing over $6B in assets, including many of the world’s top projects.

The research efforts of CertiK have received grants from IBM and the Ethereum Foundation, and notable investors include Binance Labs, Bitmain, Lightspeed Venture Partners, Matrix Partners, and NEO Global Capital, among others.

To request an audit/verification of your smart contracts, email audit@certik.io or visit certik.io to learn more

Twitter: https://twitter.com/CertiKCommunity

Reddit: https://www.reddit.com/r/CertiKOrg/

Telegram: https://t.me/certikorg

LinkedIn: https://www.linkedin.com/company/certik