Skip to content
Log inStart free trial

GHSA-69v6-xc2j-r2jf CVE-2020-26241 GO-2022-0771

Shallow copy bug in geth

Medium Go
Severity
6.5 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
1.23%
Chance of exploitation in the next 30 days. Higher than 68.85% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-682 Incorrect Calculation
Fix
1.9.17
Upgrade github.com/ethereum/go-ethereum to this version or later

Description

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:

Affected versions

Go

PackageVulnerableFixed in
github.com/ethereum/go-ethereum
>= 1.9.7, < 1.9.17
1.9.17

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/ethereum/go-ethereum Go → 1.9.17

go
go get github.com/ethereum/go-ethereum@v1.9.17 && go mod tidy

Severity breakdown

CVSS 3.1 6.5

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

Weakness

CWE-682: Incorrect Calculation

The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.

How to prevent it
  • Implementation: Understand your programming language's underlying representation and how it interacts with numeric calculation. Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how your language handles numbers that are too large or too small for its underlying representation.
  • Implementation: Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.
  • Implementation: Use the appropriate type for the desired action. For example, in C/C++, only use unsigned types for values that could never be negative, such as height, width, or other numbers related to quantity.
  • Architecture and Design: Use languages, libraries, or frameworks that make it easier to handle numbers without unexpected consequences. Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).
  • Architecture and Design: Use languages, libraries, or frameworks that make it easier to handle numbers without unexpected consequences. Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).
  • Implementation: Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.

References

Advisories

Packages

Other links

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-m6j8-rg6r-7mv8
Go Ethereum Improperly Validates the ECIES Public Key in RLPx Handshake
High Also affects github.com/ethereum/go-ethereum
GHSA-2gjw-fg97-vg3r
Go Ethereum affected by DoS via malicious p2p message
High Also affects github.com/ethereum/go-ethereum
GHSA-689v-6xwf-5jf3
Go Ethereum affected by DoS via malicious p2p message
High Also affects github.com/ethereum/go-ethereum
GHSA-mq3p-rrmp-79jg
go-ethereum is vulnerable to high CPU usage leading to DoS via malicious p2p message
High Also affects github.com/ethereum/go-ethereum
GHSA-mr7q-c9w9-wh4h
go-ethereum is vulnerable to DoS via malicious p2p message affecting a vulnerable node
High Also affects github.com/ethereum/go-ethereum
GHSA-q26p-9cq4-7fc2
Go Ethereum vulnerable to DoS via malicious p2p message
Medium Also affects github.com/ethereum/go-ethereum
GHSA-4xc9-8hmq-j652
go-ethereum vulnerable to DoS via malicious p2p message
High Also affects github.com/ethereum/go-ethereum
GHSA-v9jh-j8px-98vq
go-ethereum vulnerable to denial of service via crafted GraphQL query
High Also affects github.com/ethereum/go-ethereum
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor