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
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
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
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
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.
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).
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 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, with commit f1fd963, and released as part of Geth 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 Email us at security@ethereum.org
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
Workarounds
No workarounds exist, save to update and/or apply the patch commit.
References.
Post-mortem write-up.
Credits
The bug was found by @guidovranken (working for Sentnl during an audit of the Telos EVM) and reported via bounty@ethereum.org.
For more information If you have any questions or comments about this advisory:
Open an issue in go-ethereum Email us at security@ethereum.org
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