2 days ago · 3 min read
Ethereum › Hacks
Ethereum Constantinople Fork Delayed After Detecting Introduced Smart Contract Vulnerabilities
A security firm identified a vulnerability introduced by the planned January 16th Constantinople hard fork, compelling the core Ethereum developers to issue an emergency postponement.
A security firm identified a vulnerability introduced by the planned Jan. 16th Constantinople hard fork, compelling the core Ethereum developers to issue an emergency postponement.
On Jan. 15th, 2019, ChainSecurity—a smart contract auditing and security firm—detected a vulnerability introduced by the Constantinople hard fork upgrade. The vulnerability would allow funds to be stolen from smart contracts that utilize op-codes (code that makes certain processes easier for developers) that were scheduled for update.
Today, the Ethereum Foundation issued an emergency announcement to coordinate necessary precautions. Anyone running a node, including exchanges, miners, and wallet services, will need to update to a new version of Geth or Parity before block 7,080,000, which will occur approximately on Jan. 17th, 04:00 UTC.
Appropriate fixes will be made in the next 3-4 hours, according to the announcement. Furthermore, so long as parties running a node upgrade to the patched version of the software, then there should not be any damage caused by the vulnerability.
Meanwhile, individuals holding or interacting with Ethereum do not need to do anything, according to the announcement. This includes hardware wallets such as Ledger and Trezor, front-facing clients such as MyEtherWallet, and others who do not actively participate in network syncing or node operation.
Analysis of the Vulnerability
ChainSecurity issued an in-depth post analyzing the vulnerability. Due to changes from EIP-1283, the reduced gas costs for the SSTORE operation would produce an unwanted side effect. The cheaper operation, when used in conjunction with the transfer() or send() operations in a Solidity smart contract, would result in a potential exploit.
Contracts with these operations would allow hackers to perform something called a “re-entrancy” attack after the Consantinople upgrade. Consequently, this would allow hackers to drain funds from a contract.
ChainSecurity suggested that hackers would be able to perform an “attack and continue to do so,” suggesting that the attack is repeatable until a contract is drained of funds.
Technical explanation: According to ChainSecurity, below are the following criteria that make a contract vulnerable:
- There’s a function A, where there’s a transfer/send followed by a state-changing operation. This can sometimes be “non-obvious” according to ChainSecurity, citing examples of a second transfer or interaction with another smart contract.
- There’s a function B, accessible from the attacker which changes the state AND whose state changes conflict with those of function A.
- The function B needs to be executable with less than 1600 gas.
Magnitude and Impact of the Vulnerability
Magnitude and Impact of Vulnerability
ChainSecurity performed a scan of the main Ethereum blockchain and did not find any vulnerable smart contracts in the wild. The company is also working to perform a more in-depth analysis of complex smart contracts which have not been decompiled—the process of turning computer-readable code into human-readable code, yet.
Nonetheless, since the risk is still there, the exploit could still result in scammers and other unethical projects taking advantage of the loophole to defraud people. Because of this, the postponement is understandable even if it only affects a tiny number of contracts.
Something to recognize is that from the publication of ChainSecurity’s article to the Ethereum Foundation’s official response it only took three and a half hours for them to react and issue the emergency announcement. Impressive considering the size of the organization and the number of parties involved.
According to the announcement, the official stance of the Ethereum Foundation is as follows:
“Because the risk is non-zero and the amount of time required to determine the risk with confidence is longer [than] the amount of time available before the planned Constantinople upgrade, a decision was reached to postpone the fork out of an abundance of caution.”
Questions Raised by the Postponement
Fortunately, the vulnerability was caught before the fork, rather than after the fork, where it could have resulted in damage to users. Yet, the detection of the vulnerability a day before the fork raises important ideological questions.
Blockchain systems, that are widely in-use, have an extremely high bar for security. Furthermore, in a complex system like Ethereum, these kinds of risks are inevitable. There is a tradeoff between progress and security, and every new upgrade introduces an opportunity for exploits or a community schism.
How much risk a community is willing to take on is a defining characteristic, with Bitcoin Core on one end of the spectrum, and with nimbler altcoins on the other end. It’s up to the stakeholders to decide whether the trade-off is worth it.