By Go-Ethereum (Geth) and Parity who are both key ethereum clients have released software updates following yesterday’s decision to postpone the long-awaited Constantinople hard fork after a glaring security vulnerability was discovered.
As reported by CoinBeat earlier today, the upgrade was postponed following a developers call, after ChainSecurity, an audit firm discovered a sensitive security vulnerability. The issue was found within the Ethereum Improvement Proposal (EIP) 1283, one of the planned changes of Constantinople. If the hard fork was implemented and attackers utilised this vulnerability, it would have left the network open to “reentrance attacks,” enabling malicious users with the ability to withdraw funds from one source a number of times.
It was decided that the new activation block for the upgrade will be discussed during a follow-up developer call later this week.
It gets tricky here. Since some software clients on the network had already been updated ahead of the network upgrade, to prevent the fork from happening, devs of major ethereum implementations decided to publish new versions.
Geth released their own emergency hotfix (version 1.8.21) which was built to delay the upgrade. Developer Péter Szilágyi stated that users who do not want to upgrade to the new version are able to downgrade their existing clients to version 1.8.19 or continue running the current version with an override.
In a similar fashion, Parity clients have the options of either upgrading their existing clients to 2.2.7 (the stable release) or 2.3.0 (a beta release) or they can also downgrade to 2.2.4 (beta).
Kirill Pimenov, Parity’s head of security during an ethereum core developers chat stated that he recommends that users upgrade to the latest release as opposed to downgrading:
“I want to restate — downgrading Parity to pre-Constantinople versions is a bad idea, we don’t recommend that to anyone. Theoretically, it should even work, but we don’t want to deal with that mess.”
Parity release manager Afri Schoedon, also told a news outlet that he recommends upgrading to 2.2.7 but also noted that the other two options would work as well.
Hudson Jameson, a core developer, wrote in a blog post that any person not running a node or participating on the network need not do anything.
He stated that smart contract owners need not to worry though “you may choose to examine the analysis of the potential vulnerability and check your contracts.”
Furthermore, he also pointed out that the change which would open the network to the potential threat would not be enabled.
The Potential For Reentrance Attacks:
At present, no instances of the security risk which was found yesterday have been found in live contracts. Jameson, however, Jameson did note that “there is still a non-zero risk that some contracts could be affected.”
To prevent reentrance attacks on transfers upon the network, a small amount of ether called gas is charged which usually prevents malicious users from repeating transfers in order to steal additional funds.
Hubert Ritzdorf, however, who found the weakness in security explained that a “side effect” of EIP 1283 allows attackers to leverage the small amount of gas for malicious activities.
Ritzdorf explained:
“The difference is before you couldn’t do something malicious with this little bit of gas, you could do something useful but not something malicious and now because some of the operations became cheaper, now you can do something malicious with this little bit of gas.”
Despite the fact that reentrancy is an issue that all smart contract developers regularly consider when writing code in Solidity on ethereum ChainSecurity’s COO Matthias Egli stated that core developers who are working on mechanics of the virtual machine could have easily missed the vulnerability:
He explained:
“It’s a Solidity thing, it’s not an [ethereum virtual machine] core thing that in practice allowed this attack. That was part of this disconnect that in practice small changes to gas cost will allow new kind of attacks which wasn’t considered before.”
Furthermore, Ritzdorf went on to explain that the fix to the problem is not as easy as just updating gas costs on the network:
“if we change this amount to a small number now then we would fix the vulnerability but we would also break many existing [smart] contracts.”
As a result of this, the Constantinople upgrade was delayed and was the best call by the core developers said, Egli:
“It was the right decision because it at least buys some time for researchers to evaluate the real world impact. With high likelihood, this [EIP] will be taken back and not included in the upcoming hard fork which is now delayed by perhaps a month.”
What Are The Next Steps?
At the time of press, developers had already started contacting exchanges, wallet services, mining pools and all groups who use or interact with the ETH network.
Notably, core devs are also planning discussions around the long-term steps which includes the proper time to roll out the Constantinople upgrade as well as a solution to fixing the EIP 1283 bug during another developer call set to happen on the 18th of January.
A number of developers have suggested the implementation of a bug bounty program with a core focus on analysing the code in an effort to ensure that any future bugs discovered are found in advance as opposed than “right before [hard fork] day.”
Will these new eyes unearth any more bugs and will this affect and delay the hard fork again? Let us know your thoughts by leaving a comment below.
Follow CoinBeat on Facebook, Twitter & Telegram
Subscribe to our CoinBeat Newsletter
Submit an article to CoinBeat
View live Marketcap Prices here
Comments