Major ethereum clients, including Go-Ethereum (Geth) and Parity, have released software updates following an earlier decision to delay the planned system-wide upgrade dubbed Constantinople.
The upgrade was postponed Tuesday during a developers call, a move that came after blockchain audit firm Chain Security discovered a security vulnerability in Ethereum Improvement Proposal (EIP) 1283, one of the planned changes included in Constantinople. If exploited, the bug would have allowed for “reentrance attacks,” allowing malicious actors to withdraw funds from the same source multiple times.
A new activation block for the upgrade will be decided during another call later this week.
In order to prevent the fork from happening – given that some of the software clients on the network had already been updated ahead of the fork – developers of the major ethereum implementations moved to publish new versions.
Geth released an emergency hotfix (version 1.8.21) designed to delay the upgrade, though developer Péter Szilágyi noted that users who do not wish to upgrade to the new version of the client can also downgrade their existing clients to version 1.8.19 or continue running the current version (1.8.20) with an override.
Parity clients can similarly either upgrade their existing clients to 2.2.7 (the stable release) or 2.3.0 (a beta release) or otherwise downgrade to 2.2.4 (beta).
Parity Technologies head of security Kirill Pimenov, speaking in an ethereum core developers chat on Gitter, said he recommended users upgrade to the new release, rather than downgrade to an older version, explaining:
“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.”
Similarly, Parity release manager Afri Schoedon told CoinDesk that he recommends 2.2.7, though the other two should work as well.
In a blog post, core developer Hudson Jameson wrote that anyone who does not run a node or otherwise participate in the network does not need to do anything.
Smart contract owners do not need to do anything either, though “you may choose to examine the analysis of the potential vulnerability and check your contracts,” he wrote.
However, he pointed out that the change that could introduce the potential issue will not be enabled.
As of the blog post’s publication, security researchers with ChainSecurity, who initially discovered the bug, and TrailOfBits are analyzing the overall blockchain.
Reentrance attacks
So far, no instances of the vulnerability have been discovered in live contracts. However, Jameson noted that “there is still a non-zero risk that some contracts could be affected.”
In order for transfers on ethereum to avoid reentrance attacks, a small amount of ether called gas is paid which prevents attackers from repurposing a transfer to steal funds.
However, as explained to CoinDesk by Hubert Ritzdorf – the individual who found the vulnerability and CTO of Chain Security – a “side effect” of EIP 1283 ensures attackers can leverage this small amount of gas for malicious purposes.
“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,” said Ritzdorf.
And though the issue of reentrancy is always on the minds of smart contract developers coding in Solidity on ethereum, Matthias Egli – COO of Chain Security – explained that core developers strictly looking at the mechanics of the virtual machine couldn’t have easily spotted this vulnerability.
He told CoinDesk:
“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.”
What’s more, Ritzdorf added that the fix to this issue isn’t as easy as updating ethereum’s gas cost limits, explaining that “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 such, for the time being, a delay to Constantinople was the right call by core developers according to 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,” he contended.
Next steps
As of press time, developers are contacting exchanges, wallets, mining pools and other groups which use or interact with the ethereum network.
Core developers plan to discuss longer-term steps – including when to execute Constantinople and how to fix the bug in EIP 1283 – during another call on Jan. 18.
Multiple developers suggested initiating some sort of bug bounty program focused on analyzing the code, in order to ensure future bugs are discovered well in advance, rather than “right before [hard fork] day.”
Szilágyi noted that the EIP had been available for review for nearly a year, adding that “maybe it’s not a bad idea to do some grants for more focused eyes.”
Code image via Shutterstock
https://www.coindesk.com/ethereum-new-software-hard-fork-delay-constantinople
