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

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.

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 exponential ReDoS (Regular Expression Denial of Service) can be triggered in the eth-account PyPI package, when an attacker is able to supply arbitrary input to the encodestructureddata method

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.

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.

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

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

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

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

A stack overflow vulnerability in Aleth Ethereum C++ client version <= 1.8.0 using a specially crafted a config.json file may result in a denial of service.

Go Ethereum, or "Geth", is the official Golang implementation of the Ethereum protocol. In Geth before version 1.9.25 a denial-of-service vulnerability can make a LES server crash via malicious GetProofsV2 request from a connected LES client. This vulnerability only concerns users explicitly enabling les server; disabling les prevents the exploit. The vulnerability was patched in version 1.9.25.

Go Ethereum, or "Geth", is the official Golang implementation of the Ethereum protocol. In Geth from version 1.9.4 and before version 1.9.20 a consensus-vulnerability could cause a chain split, where vulnerable versions refuse to accept the canonical chain. The fix was included in the Paragade release version 1.9.20. No individual workaround patches have been made -- all users are recommended to upgrade to a newer version.

An exploitable out-of-bounds read vulnerability exists in libevm (Ethereum Virtual Machine) of CPP-Ethereum. A specially crafted smart contract code can cause an out-of-bounds read which can subsequently trigger an out-of-bounds write resulting in remote code execution. An attacker can create/send malicious smart contract to trigger this vulnerability.

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

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

An issue was discovered in EthereumJ 1.8.2. There is Unsafe Deserialization in ois.readObject in mine/Ethash.java and decoder.readObject in crypto/ECKey.java. When a node syncs and mines a new block, arbitrary OS commands can be run on the server.