github.com/ethereum/go-ethereum known bugs

Go-Ethereum v1.10.9 was discovered to contain an issue which allows attackers to cause a denial of service (DoS) via sending an excessive amount of messages to a node. This is caused by missing memory in the component /ethash/algorithm.go.

A design flaw in all versions of Go-Ethereum allows an attacker node to send 5120 pending transactions of a high gas price from one account that all fully spend the full balance of the account to a victim Geth node, which can purge all of pending transactions in a victim node's memory pool and then occupy the memory pool to prevent new transactions from entering the pool, resulting in a denial of service (DoS).

Geth (aka go-ethereum) through 1.13.4, when `--http --graphql` is used, allows remote attackers to cause a denial of service (memory consumption and daemon hang) via a crafted GraphQL query. NOTE: the vendor's position is that the "graphql endpoint [is not] designed to withstand attacks by hostile clients, nor handle huge amounts of clients/traffic.

In Go Ethereum (aka geth) before 1.8.14, TraceChain in eth/api_tracer.go does not verify that the end block is after the start block. ### Specific Go Packages Affected github.com/ethereum/go-ethereum/eth

A design flaw in Go-Ethereum 1.10.12 and older versions allows an attacker node to send 5120 future transactions with a high gas price in one message, which can purge all of pending transactions in a victim node's memory pool, causing a denial of service (DoS).

### Impact A vulnerable node, can be made to consume unbounded amounts of memory when handling specially crafted p2p messages sent from an attacker node. ### Details The p2p handler spawned a new goroutine to respond to `ping` requests. By flooding a node with ping requests, an unbounded number of goroutines can be created, leading to resource exhaustion and potentially crash due to OOM. ### Patches The fix is included in geth version `1.12.1-stable`, i.e, `1.12.2-unstable` and onwards. Fixed by https://github.com/ethereum/go-ethereum/pull/27887 ### Workarounds No known workarounds. ### Credits This bug was reported by Patrick McHardy and reported via [[email protected]](mailto:[email protected]). ### References

The GetBlockHeadersMsg handler in the LES protocol implementation in Go Ethereum (aka geth) before 1.8.11 may lead to an access violation because of an integer signedness error for the array index, which allows attackers to launch a Denial of Service attack by sending a packet with a -1 query.Skip value. The vulnerable remote node would be crashed by such an attack immediately, aka the EPoD (Ethereum Packet of Death) issue. ### Specific Go Packages Affected github.com/ethereum/go-ethereum/les

**Impact** A vulnerable node can be forced to shutdown/crash using a specially crafted message. More details to be released later. **Credit** This issue was reported to the Ethereum Foundation Bug Bounty Program by DELENE TCHIO ROMUALD.

**Impact** An attacker can cause high CPU usage by sending a specially crafted p2p message. More details to be released later. **Credit** This issue was reported to the Ethereum Foundation Bug Bounty Program by @Yenya030

`cmd/evm/runner.go` in Go Ethereum (aka geth) allows attackers to cause a denial of service (SEGV) via crafted bytecode. ### Specific Go Packages Affected github.com/ethereum/go-ethereum/cmd/evm

### Impact A vulnerable node can be made to consume very large amounts of memory when handling specially crafted p2p messages sent from an attacker node. In order to carry out the attack, the attacker establishes a peer connections to the victim, and sends a malicious `GetBlockHeadersRequest` message with a `count` of `0`, using the `ETH` protocol. In `descendants := chain.GetHeadersFrom(num+count-1, count-1)`, the value of `count-1` is passed to the function `GetHeadersFrom(number, count uint64)` as parameter `count`. Due to integer overflow, `UINT64_MAX` value is then passed as the `count` argument to function `GetHeadersFrom(number, count uint64)`. This allows an attacker to bypass `maxHeadersServe` and request all headers from the latest block back to the genesis block. ### Patches The fix has been included in geth version `1.13.15` and onwards. The vulnerability was patched in: https://github.com/ethereum/go-ethereum/pull/29534 ### Workarounds No workarounds have been made public. ### References No more information is released at this time. ### Credit This issue was disclosed responsibly by DongHan Kim via the Ethereum bug bounty program. Thank you for your cooperation.

### Impact A vulnerable node can be forced to shutdown/crash using a specially crafted message. More details to be released later. ### Patches The problem is resolved in the v1.16.9 and v1.17.0 releases of Geth. ### Credit This issue was reported to the Ethereum Foundation Bug Bounty Program by Waleed Ahmed from vulsight.com

Go Ethereum Improperly Validates the ECIES Public Key in RLPx Handshake in github.com/ethereum/go-ethereum

Go Ethereum affected by DoS via malicious p2p message in github.com/ethereum/go-ethereum

Go Ethereum affected by crash via malicious p2p message in github.com/ethereum/go-ethereum

DoS via malicious p2p message affecting a vulnerable node in github.com/ethereum/go-ethereum

High CPU usage leading to DoS via malicious p2p message in github.com/ethereum/go-ethereum

Go Ethereum vulnerable to DoS via malicious p2p message in github.com/ethereum/go-ethereum

A vulnerable node can be made to consume very large amounts of memory when handling specially crafted p2p messages sent from an attacker node. This can result in a denial of service as the node runs out of memory.

Unbounded memory consumption in github.com/ethereum/go-ethereum

Go Ethereum Improper Input Validation in github.com/ethereum/go-ethereum

Go Ethereum Denial of Service in github.com/ethereum/go-ethereum

Erroneous Proof of Work calculation in geth in github.com/ethereum/go-ethereum

Shallow copy bug in geth in github.com/ethereum/go-ethereum

DoS via malicious p2p message in Go Ethereum in github.com/ethereum/go-ethereum

Denial of service in go-ethereum due to CVE-2020-28362 in github.com/ethereum/go-ethereum

A maliciously crafted snap/1 protocol message can cause a panic.

A vulnerability in the Geth EVM can cause a node to reject the canonical chain. A memory-corruption bug within the EVM can cause a consensus error, where vulnerable nodes obtain a different stateRoot when processing a maliciously crafted transaction. This, in turn, would lead to the chain being split in two forks.

Due to an incorrect state calculation, a specific set of transactions could cause a consensus disagreement, causing users of this package to reject a canonical chain.

Due to improper argument validation in RPC messages, a maliciously crafted message can cause a panic, leading to denial of service.

Due to a nil pointer dereference, a maliciously crafted RPC message can cause a panic. If handling RPC messages from untrusted clients, this may be used as a denial of service vector.

### Impact A consensus-vulnerability in Geth could cause a chain split, where vulnerable versions refuse to accept the canonical chain. ### Description A flaw was repoted at 2020-08-11 by John Youngseok Yang (Software Platform Lab), where a particular sequence of transactions could cause a consensus failure. - Tx 1: - `sender` invokes `caller`. - `caller` invokes `0xaa`. `0xaa` has 3 wei, does a self-destruct-to-self - `caller` does a `1 wei` -call to `0xaa`, who thereby has 1 wei (the code in `0xaa` still executed, since the tx is still ongoing, but doesn't redo the selfdestruct, it takes a different path if callvalue is non-zero) - Tx 2: - `sender` does a 5-wei call to 0xaa. No exec (since no code). In geth, the result would be that `0xaa` had `6 wei`, whereas OE reported (correctly) `5` wei. Furthermore, in geth, if the second tx was not executed, the `0xaa` would be destructed, resulting in `0 wei`. Thus obviously wrong. It was determined that the root cause was this [commit](https://github.com/ethereum/go-ethereum/commit/223b950944f494a5b4e0957fd9f92c48b09037ad) from [this PR](https://github.com/ethereum/go-ethereum/pull/19953). The semantics of `createObject` was subtly changd, into returning a non-nil object (with `deleted=true`) where it previously did not if the account had been destructed. This return value caused the new object to inherit the old `balance`: ```golang func (s *StateDB) CreateAccount(addr common.Address) { newObj, prev := s.createObject(addr) if prev != nil { newObj.setBalance(prev.data.Balance) } } ``` It was determined that the minimal possible correct fix was ```diff +++ b/core/state/statedb.go @@ -589,7 +589,10 @@ func (s *StateDB) createObject(addr common.Address) (newobj, prev *stateObject) s.journal.append(resetObjectChange{prev: prev, prevdestruct: prevdestruct}) } s.setStateObject(newobj) - return newobj, prev + if prev != nil && !prev.deleted { + return newobj, prev + } + return newobj, nil ``` ### Patches See above. The fix was included in Geth `v1.9.20` "Paragade". ### Credits The bug was found by @johnyangk and reported via [email protected]. ### For more information If you have any questions or comments about this advisory: * Open an issue in [go-ethereum](https://github.com/ethereum/go-ethereum) * Email us at [[email protected]](mailto:[email protected])

### Impact A vulnerable node, if configured to use high verbosity logging, can be made to crash when handling specially crafted p2p messages sent from an attacker node. ### Patches The following PR addresses the problem: https://github.com/ethereum/go-ethereum/pull/24507 ### Workarounds Aside from applying the PR linked above, setting loglevel to default level (`INFO`) makes the node not vulnerable to this attack. ### Credits This bug was reported by `nrv` via [email protected], who has gracefully requested that the bounty rewards be donated to Médecins sans frontières. ### For more information If you have any questions or comments about this advisory: * Open an issue in [go-ethereum](https://github.com/ethereum/go-ethereum)

### Impact An ethash mining DAG generation flaw in Geth could cause miners to erroneously calculate PoW in an upcoming epoch (estimated early January, 2021). This happened on the ETC chain on 2020-11-06. This issue is relevant only for miners, non-mining nodes are unaffected. ### Patches This issue is also fixed as of 1.9.24. Thanks to @slavikus for bringing the issue to our attention and writing the fix. ### Workarounds This PR implements a patch: https://github.com/ethereum/go-ethereum/pull/21793 ### References https://blog.ethereum.org/2020/11/12/geth_security_release/ ### For more information If you have any questions or comments about this advisory: * Open an issue in [go-ethereum](https://github.com/ethereum/go-ethereum) * Email us at [[email protected]](mailto:[email protected])

Go Ethereum (aka geth) through 1.10.21 allows attackers to increase rewards by mining blocks in certain situations, and using a manipulation of time-difference values to achieve replacement of main-chain blocks, aka Riskless Uncle Making (RUM), as exploited in the wild in 2020 through 2022.

### Impact A DoS vulnerability can make a LES server crash via malicious `GetProofsV2` request from a connected LES client. ### Patches The vulnerability was patched in https://github.com/ethereum/go-ethereum/pull/21896. ### Workarounds This vulnerability only concerns users explicitly enabling `les` server; disabling `les` prevents the exploit. It can also be patched by manually applying the patch in https://github.com/ethereum/go-ethereum/pull/21896. ### For more information If you have any questions or comments about this advisory: * Open an issue in [go-ethereum](https://github.com/ethereum/go-ethereum) * Email us at [[email protected]](mailto:[email protected])

### Impact A vulnerable node can be forced to shutdown/crash using a specially crafted message. During the peer-to-peer connection handshake, a shared secret key is computed. The implementation did not verify whether the EC public key provided by the remote party is a valid point on the secp256k1 curve. By simply sending an all-zero public key, a crash could be induced due to unexpected results from the handshake. The issue was fixed by adding a curve point validity check in https://github.com/ethereum/go-ethereum/commit/159fb1a1db551c544978dc16a5568a4730b4abf3 ### Patches A fix has been included in geth version 1.14.13 and onwards. ### Workarounds Unfortunately, no workaround is available. ### Credits This issue was originally reported to Polygon Security by David Matosse (@iam-ned).

### Impact Through a flaw in the ECIES cryptography implementation, an attacker may be able to extract bits of the p2p node key. ### Patches The issue is resolved in the v1.16.9 and v1.17.0 releases of Geth. We recommend rotating the node key after applying the upgrade, which can be done by removing the file `<datadir>/geth/nodekey` before starting Geth. ### Credit The issue was reported as a public pull request to go-ethereum by @fengjian.

### Impact Denial-of-service (crash) during block processing ### Details Affected versions suffer from a vulnerability which can be exploited through the `MULMOD` operation, by specifying a modulo of `0`: `mulmod(a,b,0)`, causing a `panic` in the underlying library. The crash was in the `uint256` library, where a buffer [underflowed](https://github.com/holiman/uint256/blob/4ce82e695c10ddad57215bdbeafb68b8c5df2c30/uint256.go#L442). if `d == 0`, `dLen` remains `0` and https://github.com/holiman/uint256/blob/4ce82e695c10ddad57215bdbeafb68b8c5df2c30/uint256.go#L451 will try to access index `[-1]`. The `uint256` library was first merged in this [commit](https://github.com/ethereum/go-ethereum/commit/cf6674539c589f80031f3371a71c6a80addbe454), on 2020-06-08. Exploiting this vulnerabilty would cause all vulnerable nodes to drop off the network. The issue was brought to our attention through a [bug report](https://github.com/ethereum/go-ethereum/issues/21367), showing a `panic` occurring on sync from genesis on the Ropsten network. It was estimated that the least obvious way to fix this would be to merge the fix into `uint256`, make a new release of that library and then update the geth-dependency. - https://github.com/holiman/uint256/releases/tag/v1.1.1 was made the same day, - PR to address the issue: https://github.com/holiman/uint256/pull/80 - PR to update geth deps: https://github.com/ethereum/go-ethereum/pull/21368 ### Patches Upgrade to v1.9.18 or higher ### Workarounds Not at this time ### References https://blog.ethereum.org/2020/11/12/geth_security_release/ ### For more information If you have any questions or comments about this advisory: * Open an issue in [go-ethereum](https://github.com/ethereum/go-ethereum) * Email us at [[email protected]](mailto:[email protected])

### Impact A vulnerability in the Geth EVM could cause a node to reject the canonical chain. ### Description A memory-corruption bug within the EVM can cause a consensus error, where vulnerable nodes obtain a different `stateRoot` when processing a maliciously crafted transaction. This, in turn, would lead to the chain being split in two forks. All Geth versions supporting the London hard fork are vulnerable (which predates London), so all users should update. This bug was exploited on Mainnet at block 13107518, leading to a minority chain split. ### Patches A patch is included in the `v1.10.8` release. The exact patch to fix the issue is contained within this [commit](https://github.com/ethereum/go-ethereum/pull/23381/commits/4d4879cafd1b3c906fc184a8c4a357137465128f) ### Workarounds No workarounds exist, save to update and/or apply the patch commit. ### References. Post-mortem [write-up](https://github.com/ethereum/go-ethereum/blob/master/docs/postmortems/2021-08-22-split-postmortem.md). ### Credits The bug was found by @guidovranken (working for [Sentnl](https://sentnl.io/) during an audit of the [Telos EVM](https://www.telos.net/evm)) and reported via [email protected]. ### For more information If you have any questions or comments about this advisory: * Open an issue in [go-ethereum](https://github.com/ethereum/go-ethereum/) * Email us at [[email protected]](mailto:[email protected])

### Impact This is a Consensus vulnerability, which can be used to cause a chain-split where vulnerable nodes reject the canonical chain. Geth’s pre-compiled `dataCopy` (at `0x00...04`) contract did a shallow copy on invocation. 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, a consensus-compliant node would push `X` on the EVM stack, whereas Geth would push `Y`. ### Patches No standalone patches have been made. ### Workarounds Upgrade to `1.9.17` or higher. ### References https://blog.ethereum.org/2020/11/12/geth_security_release/ ### For more information If you have any questions or comments about this advisory: * Open an issue in [go-ethereum](https://github.com/ethereum/go-ethereum) * Email us at [[email protected]](mailto:[email protected])

### Impact An attacker can cause high memory usage by sending a specially-crafted p2p message. More details to be released later. ### Patches The issue is resolved in the v1.17.0 release. ### Credit This issue was reported to the Ethereum Foundation Bug Bounty Program by @revofusion

Go-Ethereum 1.10.9 nodes crash (denial of service) after receiving a serial of messages and cannot be recovered. They will crash with "runtime error: invalid memory address or nil pointer dereference" and arise a SEGV signal.

### Impact A vulnerable node is susceptible to crash when processing a maliciously crafted message from a peer, via the `snap/1` protocol. The crash can be triggered by sending a malicious `snap/1` `GetTrieNodes` package. ### Details On September 21, 2021, geth-team member Gary Rong (@rjl493456442) found a way to crash the snap request handler . By using this vulnerability, a peer connected on the `snap/1` protocol could cause a vulnerable node to crash with a `panic`. In the `trie.TryGetNode` implementation, if the requested path is reached, the associated node will be returned. However the nilness is not checked there. ```golang func (t *Trie) tryGetNode(origNode node, path []byte, pos int) (item []byte, newnode node, resolved int, err error) { // If we reached the requested path, return the current node if pos >= len(path) { // Although we most probably have the original node expanded, encoding // that into consensus form can be nasty (needs to cascade down) and // time consuming. Instead, just pull the hash up from disk directly. var hash hashNode if node, ok := origNode.(hashNode); ok { hash = node } else { hash, _ = origNode.cache() } ``` More specifically the `origNode` can be nil(e.g. the child of fullnode) and system can panic at line `hash, _ = origNode.cache()`. When investigating this, @holiman tried to find it via fuzzing, which uncovered a second crasher, also related to the snap `GetTrieNodes` package. If the caller requests a storage trie: ```golang // Storage slots requested, open the storage trie and retrieve from there account, err := snap.Account(common.BytesToHash(pathset[0])) loads++ // always account database reads, even for failures if account == nil { break } stTrie, err := trie.NewSecure(common.BytesToHash(account.Root), triedb) ``` The code assumes that `snap.Account` returns _either_ a non-nil response unless `error` is also provided. This is however not the case, since `snap.Account` can return `nil, nil`. ### Patches ```diff --- a/eth/protocols/snap/handler.go +++ b/eth/protocols/snap/handler.go @@ -469,7 +469,7 @@ func handleMessage(backend Backend, peer *Peer) error { // Storage slots requested, open the storage trie and retrieve from there account, err := snap.Account(common.BytesToHash(pathset[0])) loads++ // always account database reads, even for failures - if err != nil { + if err != nil || account == nil { break } stTrie, err := trie.NewSecure(common.BytesToHash(account.Root), triedb) diff --git a/trie/trie.go b/trie/trie.go index 7ea7efa835..d0f0d4e2bc 100644 --- a/trie/trie.go +++ b/trie/trie.go @@ -174,6 +174,10 @@ func (t *Trie) TryGetNode(path []byte) ([]byte, int, error) { } func (t *Trie) tryGetNode(origNode node, path []byte, pos int) (item []byte, newnode node, resolved int, err error) { + // If non-existent path requested, abort + if origNode == nil { + return nil, nil, 0, nil + } // If we reached the requested path, return the current node if pos >= len(path) { // Although we most probably have the original node expanded, encoding @@ -193,10 +197,6 @@ func (t *Trie) tryGetNode(origNode node, path []byte, pos int) (item []byte, new } // Path still needs to be traversed, descend into children switch n := (origNode).(type) { - case nil: - // Non-existent path requested, abort - return nil, nil, 0, nil - case valueNode: // Path prematurely ended, abort return nil, nil, 0, nil ``` The fixes were merged into [#23657](https://github.com/ethereum/go-ethereum/pull/23657), with commit [f1fd963](https://github.com/ethereum/go-ethereum/pull/23657/commits/f1fd963a5a965e643e52fcf805a2a02a323c32b8), and released as part of Geth [v1.10.9](https://github.com/ethereum/go-ethereum/tree/v1.10.9) on Sept 29, 2021. ### Workarounds Apply the patch above or upgrade to a version which is not vulnerable. ### For more information If you have any questions or comments about this advisory: * Open an issue in [go-ethereum](https://github.com/ethereum/go-ethereum/) * Email us at [[email protected]](mailto:[email protected])

### Impact 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 the underlying 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`. ### Patches This is not an issue in go-ethereum, rebuilding an older version with Go `1.15.5` or `1.14.12` will suffice to address the vulnerability. ### Workarounds Rebuilding with Go `1.15.5` or `1.14.12` will suffice to address the vulnerability. ### References - https://blog.ethereum.org/2020/11/12/geth_security_release/ - https://groups.google.com/g/golang-announce/c/NpBGTTmKzpM ### For more information If you have any questions or comments about this advisory: * Open an issue in [go-ethereum](https://github.com/ethereum/go-ethereum) * Email us at [[email protected]](mailto:[email protected])