Buterin Addresses Concerns Regarding Potential Attack Vectors in Upcoming Ethereum Upgrade

  • Ethereum developers concerned about potential security vulnerabilities in new smart contract code.
  • Buterin addresses concerns from other developers regarding potential attack vectors once Constantinople is activated.

Several Ethereum (ETH) developers have expressed concerns regarding a potential security vulnerability in a new type of smart contract creation feature - which will be integrated into Ethereum’s codebase in its upcoming Constantinople hard fork upgrade.

In response to these concerns, Ethereum co-founder Vitalik Buterin stated, during a developers meeting on February 15, that the scheduled codebase modifications will not create vulnerabilities on the Ethereum blockchain . According to statements from other Ethereum developers, the “Skinny CREATE2” feature, which is part of the ethereum improvement proposal (EIP) 1014, could potentially introduce a security threat to the Ethereum network.

As CryptoGlobe covered, “Skinny CREATE2” allows users to interact with a smart contract that has not yet been issued on the Ethereum blockchain. As explained by Ethereum’s developers, “Skinny CREATE2” enables interactions with “addresses that do not exist yet on-chain but can be relied on to only possibly eventually contain code.” This feature may be exploited because smart contracts could be programmed to alter their address after they’ve been issued, according to several Ethereum developers.

Independent Blockchain Researcher Expresses His Concerns

Rajeev Gopalakrishna, an independent researcher on Ethereum and cybersecurity, has said that CREATE2 might have negative security implications for the Ethereum network. Gopalakrishna, who earned his Phd in computer science from Purdue University, explained that in certain cases, using the CREATE2 function might allow an attacker to replace a previously benign smart contract with a malicious one. Meanwhile, Jason Carver, an engineer at the Ethereum Foundation, has argued that potential attack vectors could be introduced by replacing a self-destruct contract with a newer version (by using CREATE2).

Notably, Gopalakrishna raised the following questions (earlier this month): 

Doesn’t this change a major invariant assumed by users today and introduce a potentially serious attack vector with CREATE2? Doesn’t this mean that any contract post-Constantinople with a selfdestruct [function call] is now more suspect than before?

"Non-Deterministic Init Codes Are A Problem"

Responding to these questions, Ethereum developer Jeff Coleman noted: 

"One of the things that is counter-intuitive about CREATE2 is that theoretically redeployments can change the contract byte code, because the address is only a commitment to the init code. People need to be aware that init codes are part of auditing, [...] that non-deterministic init codes are a problem.”

According to blockchain developer, Noel Maersk, the self-destruct function by itself may not have negative security implications. Maersk also argued that adding non-deterministic init (initialization) code to smart contracts issued on a CREATE2-enabled blockchain might potentially introduce attack vectors.

Moreover, Coleman pointed out that developers planning to audit code written by other programmers must look out for “weird phenomena ... especially if you combine CREATE2 with CREATE1, because the latter has a really weak assumption around address identity whatever the nonce is.”

Buterin's Comments On CREATE2, Ethereum's Long-Term Roadmap

Coleman suggested “throwing out the idea of a contract nonce” is possible if CREATE2 is set as the “standard” - while “getting rid of [the] self destruct” function completely. He stressed the need for “content-based addressing” of smart contracts rather than only relying on “order-based addressing” - “which is what CREATE1 is.”

Buterin also discussed the implications of CREATE2 and Ethereum’s long-term roadmap: 

The one thing we need to keep in mind is more for the future, when thinking about rents and deletion; that’s a way that can lead to contracts being in a state to being not in a state without a self-destruct operation ... It’s not something we need to figure out in the next few weeks, but it's still useful to keep in mind when getting the ETH 2.0 sharding to a VM (virtual machine) spec very soon.