Summary
Versions of geth built with Go <1.15.5 or <1.14.12 are most likely affected by a critical DoS-related security vulnerability. The golang team has registered this flaw as ‘CVE-2020-28362’.
We recommend all users to rebuild (ideally v1.9.24) with Go 1.15.5 or 1.14.12, to avoid node crashes. Alternatively, if you are running binaries distributed via one of our official channels, we’re going to release v1.9.24 ourselves built with Go 1.15.5.
Docker images will most probably be out of date due to a missing base image, but you can check the release notes on how to temporarily build one with Go 1.15.5. Please run geth version to verify the Go version your binary was built with.
Background
In early October, go-ethereum enrolled into Google’s OSS-Fuzz program. We had previosly executed fuzzers on an ad-hoc basis and tested some different platforms.
On 2020-10-24, we were notified that one of our fuzzers had found a crash.
Upon investigation, it turned out that the root cause of the issue was a bug in the standard libraries of Go, and the issue was reported upstream.
Special thanks to Adam Korczynski of Ada Logics for the initial integration of go-ethereum into OSS-Fuzz!
Impact
The DoS issue can be used to crash all Geth nodes during block processing, the effects of which would be that a major part of the Ethereum network went offline.
Outside of Go-Ethereum, the issue is most likely relevant for all forks of Geth (such as TurboGeth or ETC’s core-geth). For an even wider context, we would refer to upstream, as the Go-team have performed an investigation of potentially affected parties.
Timeline
- 2020-10-24: Crash report from OSS-fuzz
- 2020-10-25: Investigation found that it was due to flaw in Go. Details sent to security@golang.org
- 2020-10-26: Acknowledgement from upstream, investigation ongoing
- 2020-10-26 — 2020-11-06: Potential fixes discussed, upstream investigation of potentially affected parties
- 2020-11-06: Upstream tentatively scheduled fix-release for 2020-11-12
- 2020-11-09: Upstream pre-announced the security release: https://groups.google.com/g/golang-announce/c/kMa3eup0qhU/m/O5RSMHO_CAAJ
- 2020-11-11: Notified users about the upcoming release via the official Geth twitter account, our official Discord-channel and Reddit.
- 2020-11-12: New Go version were released, and new geth binaries were released
Additional issues
Mining flaw
Another security issue was brought to our attention via this PR, containing a fix to the ethash algorithm.
The mining flaw could cause miners to erroneously calculate PoW in an upcoming epoch. This happened on the ETC chain on 2020-11-06. It appears that this would be an issue for ETH mainnet around block 11550000 / epoch 385, which will occur early January 2021.
This issue is also fixed as of 1.9.24. This issue is relevant only for miners, non-mining nodes are unaffected.
Geth shallow copy bug
Affected: 1.9.7 – 1.9.16
Fixed: 1.9.17
Type: Consensus vulnerability
On 2020-07-15, John Youngseok Yang (Software Platform Lab) reported a consensus vulnerability in Geth.
Geth’s pre-compiled dataCopy(0x00…04) contract did a shallow copy on invocation, whereas Parity’s did a deep copy. An attacker could deploy a contract that
- writes X to an EVM memory region R,
- calls 0x00..04 with R as an argument,
- overwrites R to Y,
- and finally invokes the RETURNDATACOPY opcode.
- When this contract is invoked, Parity would push X on the EVM stack, whereas Geth would push Y.
Consequences
This was exploited on Ethereum Mainnet at block 11234873, transaction 0x57f7f9. Nodes
More context can be found in the Geth post-mortem and Infura post-mortem and here.
DoS in .16 and .17
Affected: v1.9.16,v1.9.17
Fixed: v1.9.18
Type: DoS vulnerability during block processing
A DoS vulnerability was found, and fixed in v1.9.18. We have chosen to not publish the details at this point in time.
Recommendations
In the short term, we recommend that all users upgrade to geth version v1.9.24 (which should be built with Go 1.15.5) immediately. Official releases can be found here.
If you are using Geth via Docker, there could be a few problems. If you are using ethereum/client-go, there are two things to be aware of:
- There might be a delay before the new image appears on docker hub.
- Unless the Go base images have been created quickly enough, there’s a chance that they become built with a vulnerable version of Go.
If you are building docker images yourself, (via docker build . from the repository root), then the second issue might be cause problems for you aswell.
So be careful to ensure that Go 1.15.5 is used as the base image.
In the long term, we recommend that users and miners look into alternative clients too. It is our strong feeling that the resilience of the Ethereum network should not depend on any single client implementation.
There is Besu, Nethermind, OpenEthereum and TurboGeth and others to choose from aswell.
Please report security vulnerabilities either via https://bounty.ethereum.org, or via bounty@ethereum.org or via security@ethereum.org.
