Ethereum Core developers announced on Tuesday that they would postpone their much-awaited Constantinople hard fork.
The team, which has previously settled January 16 as the official date for the Ethereum blockchain upgrade, decided to delay it after ChainSecurity found potential vulnerabilities in the code. The Switzerland-based blockchain audit firm said that Constantinople would enable “reentrancy attack,” whereby a pair of hackers can use the code to simulate a secure treasury sharing service.
[SECURITY ALERT] #Constantinople upgrade is temporarily postponed out of caution following a consensus decision by #Ethereum developers, security professionals and other community members. More information and instructions are below. https://t.co/p2znO8HGxf
— Ethereum (@ethereum) January 15, 2019
Cheaper Gas Cost Could Cause Security Issues
In retrospect, a reentrancy attack takes place when a smart contract communicates with an external Smart Contract by calling it. If the foreign entity turns out to be malicious, it may take advantage of the call function and take control of the first smart contract. The vulnerability could allow the external Smart Contract to make unexpected modifications in the host’s code. For instance, such an attacker may repeatedly withdraw Ether funds by “re-entering” at a particular line in the Code.
In the case of Constantinople, ChainSecurity blamed cheaper gas costs for fueling the possibilities of a reentrancy attack. According to the firm, two parties can jointly receive funds, decide on how to split them, and receive a payout if they agree by merely exploiting the “PaymentSharer contract” mentioned in the hard fork code.
“Before Constantinople, every storage operation would cost at least 5000 gas,” wrote Constantinople. “This far exceeded the gas stipend of 2300 sent along when calling a contract using ‘transfer’ or ‘send.'”
We are thankful to our tireless community that tests to ensure security is airtight before any release. After careful consideration, #Ethereum's #Constantinople upgrade will be postponed due to a vulnerability discovered by @chain_security.#Thirdeninghttps://t.co/INC7be2a6Q
— ConsenSys (@Consensys) January 15, 2019
The firm added that changing dirty storage slots after Constantinople would cost only 200 gas. An attacker could manipulate the victim contract code to be transformed into a dirty one: with support from a public function that changes the required variable.
“Afterward, by causing the vulnerable contract to call the attacker contract e.g.with themsg.sender.transfer(...) attacker contract can use the 2300 gas stipend to manipulate the vulnerable contract’s variable successfully,” speculated ChainSecurity.
No Vulnerable Contracts So Far
ChainSecurity did a chain-wide audit of Ethereum and found that the reentrancy bug didn’t impact any smart contract yet. The Core also added that their decision to postpone the hard fork was reached following a detailed discussion with security researchers, Ethereum stakeholders, developers, node operators and other similarly essential parties of the community.
Vitalik Buterin, the co-founder of Ethereum, stressed that a little security vulnerability does not necessarily mean that the underlying code is flawed.
“If you have N protocol features, there are N2 ways they could potentially break,” he wrote on Reddit. “I would say [that] my personal takeaway from this is to be much more explicit about writing down invariants (properties guaranteed by the protocol) that we rely on so we can check against them when changing things.”
MyCrypto.com, an open-source blockchain interface, also backed Buterin’s opinion.
For example…
– A developer wrote, audited, tested and deployed a smart contract in the past
– It is not possible to exploit the smart contract
– The Constantinople update goes live
– It is now possible to exploit the smart contract, due to the changes made in EIP1283— beta.mycrypto.com (@MyCrypto) January 15, 2019
“The implementation of EIP1283 was sound,” the company wrote in one of its tweets. “The code is fine. The idea behind it is fine. There is not a “bug” in the code of this EIP. It does what is intended. The potential vulnerability lies at the contract level—not the EVM/opcode/EIP level.”
