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).

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).

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

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

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

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

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 security flaw in the 'transfer' function of a smart contract implementation for Money Making Opportunity (MMO), an Ethereum ERC721 Non-Fungible Token (NFT) project, allows users or attackers to transfer NFTs to the zero address, leading to permanent asset loss and non-compliance with the ERC721 standard. The eth address is 0x41d3d86a84c8507a7bc14f2491ec4d188fa944e7, contract name is MoneyMakingOpportunity, and compiler version is v0.8.17+commit.8df45f5f.

Impact

Prior to ethereum crate v0.18.0, signature malleability (according to EIP-2) was only checked for "legacy" transactions, but not for EIP-2930, EIP-1559 and EIP-7702 transactions.

This is a specification deviation and therefore a high severity advisory if the ethereum crate is used for Ethereum mainnet. Note that signature malleability itself is not a security issue, and therefore if the ethereum crate is used on a single-implementation blockchain, it's a low/informational severity advisory.

Patches

The issue is fixed in ethereum v0.18.0

Workarounds

You can also manually check transaction malleability outside of the crate. But it's recommended to simply upgrade the version.

References

See PR: https://github.com/rust-ethereum/ethereum/pull/67

Go Ethereum is the official Golang implementation of the Ethereum protocol. Prior to version 1.10.17, 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. Version 1.10.17 contains a patch that addresses the problem. As a workaround, setting loglevel to default level (INFO) makes the node not vulnerable to this attack.

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/gethsecurityrelease/

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 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.

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, 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, 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/gethsecurityrelease/ 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 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/gethsecurityrelease/

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

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, 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

Py-EVM v0.2.0-alpha.33 allows attackers to make a vm.executebytecode call that triggers computation.stack.values with '"stack": [100, 100, 0]' where b'\x' was expected, resulting in an execution failure because of an invalid opcode. This is reportedly related to "smart contracts can be executed indefinitely without gas being paid."

An issue in Ethereum Blockchain v0.1.1+commit.6ff4cd6 cause the balance to be zeroed out when the value of betsize+casino.balance exceeds the threshold.

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 bounty@ethereum.org.

References

An exploitable unhandled exception vulnerability exists in multiple APIs of CPP-Ethereum JSON-RPC. Specially crafted JSON requests can cause an unhandled exception resulting in denial of service. An attacker can send malicious JSON to trigger this vulnerability.

An exploitable improper authorization vulnerability exists in minerstart API of cpp-ethereum's JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass. An attacker can send JSON to trigger this vulnerability.

An exploitable improper authorization vulnerability exists in minersetGasPrice API of cpp-ethereum's JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass. An attacker can send JSON to trigger this vulnerability.

Go Ethereum (aka geth) 1.8.19 allows attackers to cause a denial of service (memory consumption) by rewriting the length of a dynamic array in memory, and then writing data to a single memory location with a large index number, as demonstrated by use of "assembly { mstore }" followed by a "c[0xC800000] = 0xFF" assignment.

An exploitable improper authorization vulnerability exists in adminpeers API of cpp-ethereum's JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass. An attacker can send JSON to trigger this vulnerability.

An exploitable information leak/denial of service vulnerability exists in the libevm (Ethereum Virtual Machine) create2 opcode handler of CPP-Ethereum. A specially crafted smart contract code can cause an out-of-bounds read leading to memory disclosure or denial of service. An attacker can create/send malicious a smart contract to trigger this vulnerability.

An exploitable improper authorization vulnerability exists in adminnodeInfo API of cpp-ethereum's JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass. An attacker can send JSON to trigger this vulnerability.

An exploitable improper authorization vulnerability exists in minerstop API of cpp-ethereum's JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). An attacker can send JSON to trigger this vulnerability.

An exploitable improper authorization vulnerability exists in adminaddPeer API of cpp-ethereum's JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass. An attacker can send JSON to trigger this vulnerability.