Ethereum urges Go devs to fix severe chain-split vulnerability

Ethreum project is urging developers to apply a hotfix to squash a high-severity vulnerability.

The chain-split vulnerability tracked as CVE-2021-39137, impacts “Geth,” the official Golang implementation of the Ethereum protocol.

Such flaws can cause corruption in blockchain services, and lead to massive outages, like the Ethereum network outage from last year.

Attack vector details withheld for now

This week, Ethereum project maintainers are urging Go developers using “go-ethereum” aka Geth to switch to version 1.10.8 which fixes a high-severity vulnerability.

The vulnerability in the open-source project Geth can cause a “chain-split,” meaning vulnerable Geth instances would reject accepting canonical chains.

Software security and crypto-fuzzing expert Guido Vranken of blockchain security firm Sentnl discovered the flaw during a security engagement.

Ethereum devs had given everyone an advance heads up last week regarding the upcoming version without revealing too much:

Until most developers have had the chance to upgrade to the fixed version, details on how the flaw can be exploited have been withheld out of caution:

“The exact attack vector will be provided at a later date to give node operators and dependent downstream projects time to update their nodes and software,” said Péter Szilágyi, Ethereum’s team lead.

“All Geth versions supporting the London hard fork are vulnerable (the bug is older than London), so all users should update,” continued Szilágyi.

Blockchain “chain-split” vulnerabilities are dangerous as their exploitation can cause outages, affecting cryptocurrency withdrawals and the overall integrity of the blockchain.

This happened last year when services relying on the Ethereum network suffered from an outage and withdrawal errors, again resulting from a vulnerable go-ethereum client.

Chain splits occur when different Ethereum clients don’t agree on what constitutes a valid transaction and what doesn’t.

This means, depending on what client your platform uses, the original (canonical) blockchain may appear to become “forked.”

In Ethereum, a single “canonical computer,” also referred to as the Ethereum Virtual Machine (EVM) maintains a common state or set of records that every node present on the Ethereum network agrees on.

Every Ethereum service keeps a copy of what’s on the EVM.

But, if a chain-split occurs, different blockchain services would now show mismatching records, thereby affecting the integrity and reliability of a cryptocurrency network:

ethereum chains split
A chain-split can cause discrepancy among Ethereum services now showing different records
Source: R3 Corda

“The probability after all that time for someone to accidentally trigger it is tiny,” explains R3 software engineer Dimos Raptis, who is involved in Corda blockchain development and who had analyzed Ethereum’s outage of last year.

The engineer, however, does not underestimate the possibility of malicious actors exploiting chain-split flaws.

“Opposed to that, the probability of someone maliciously triggering it if highlighted as a security issue is not insignificant,” warns the expert in his writeup.

Flaw found during Telos blockchain platform audit

Interestingly, the flaw was discovered during an audit of the Telos EVM platform, after Telos had engaged Sentnl as their auditor.

Telos is a newer-generation blockchain platform that helps with “building fast, scalable distributed applications with feeless transactions.”

“To find vulnerabilities in the Telos EVM, I engaged in deep and rigorous fuzzing, and verified that its behavior matched that of go-ethereum exactly,” said Vranken.

“Despite go-ethereum having an outstanding track record when it comes to security, the procedure was so effective that it wasn’t just instrumental in asserting the correctness of the Telos EVM, but also found a high severity issue in go-ethereum,” stated the crypto-fuzzing expert in a press release.

Blockchain services and developers relying on go-ethereum should upgrade to v1.10.8 or above. There are no workarounds available at this time.