mirror of https://github.com/ethereum/go-ethereum
Joe
2 years ago
parent
660687c2d8
commit
fc9edf08ca
@ -0,0 +1,170 @@ |
|||||||
|
[ |
||||||
|
{ |
||||||
|
"name": "CorruptedDAG", |
||||||
|
"uid": "GETH-2020-01", |
||||||
|
"summary": "Mining nodes will generate erroneous PoW on epochs > `385`.", |
||||||
|
"description": "A mining flaw could cause miners to erroneously calculate PoW, due to an index overflow, if DAG size is exceeding the maximum 32 bit unsigned value.\n\nThis occurred on the ETC chain on 2020-11-06. This is likely to trigger for ETH mainnet around block `11550000`/epoch `385`, slated to occur early January 2021.\n\nThis issue is relevant only for miners, non-mining nodes are unaffected, since non-mining nodes use a smaller verification cache instead of a full DAG.", |
||||||
|
"links": [ |
||||||
|
"https://github.com/ethereum/go-ethereum/pull/21793", |
||||||
|
"https://blog.ethereum.org/2020/11/12/geth_security_release/", |
||||||
|
"https://github.com/ethereum/go-ethereum/commit/567d41d9363706b4b13ce0903804e8acf214af49", |
||||||
|
"https://github.com/ethereum/go-ethereum/security/advisories/GHSA-v592-xf75-856p" |
||||||
|
], |
||||||
|
"introduced": "v1.6.0", |
||||||
|
"fixed": "v1.9.24", |
||||||
|
"published": "2020-11-12", |
||||||
|
"severity": "Medium", |
||||||
|
"CVE": "CVE-2020-26240", |
||||||
|
"check": "Geth\\/v1\\.(6|7|8)\\..*|Geth\\/v1\\.9\\.\\d-.*|Geth\\/v1\\.9\\.1.*|Geth\\/v1\\.9\\.2(0|1|2|3)-.*" |
||||||
|
}, |
||||||
|
{ |
||||||
|
"name": "Denial of service due to Go CVE-2020-28362", |
||||||
|
"uid": "GETH-2020-02", |
||||||
|
"summary": "A denial-of-service issue can be used to crash Geth nodes during block processing, due to an underlying bug in Go (CVE-2020-28362) versions < `1.15.5`, or `<1.14.12`", |
||||||
|
"description": "The DoS issue can be used to crash all Geth nodes during block processing, the effects of which would be that a major part of the Ethereum network went offline.\n\nOutside of Go-Ethereum, the issue is most likely relevant for all forks of Geth (such as TurboGeth or ETC’s core-geth) which is built with versions of Go which contains the vulnerability.", |
||||||
|
"links": [ |
||||||
|
"https://blog.ethereum.org/2020/11/12/geth_security_release/", |
||||||
|
"https://groups.google.com/g/golang-announce/c/NpBGTTmKzpM", |
||||||
|
"https://github.com/golang/go/issues/42552", |
||||||
|
"https://github.com/ethereum/go-ethereum/security/advisories/GHSA-m6gx-rhvj-fh52" |
||||||
|
], |
||||||
|
"introduced": "v0.0.0", |
||||||
|
"fixed": "v1.9.24", |
||||||
|
"published": "2020-11-12", |
||||||
|
"severity": "Critical", |
||||||
|
"CVE": "CVE-2020-28362", |
||||||
|
"check": "Geth.*\\/go1\\.(11(.*)|12(.*)|13(.*)|14|14\\.(\\d|10|11|)|15|15\\.[0-4])$" |
||||||
|
}, |
||||||
|
{ |
||||||
|
"name": "ShallowCopy", |
||||||
|
"uid": "GETH-2020-03", |
||||||
|
"summary": "A consensus flaw in Geth, related to `datacopy` precompile", |
||||||
|
"description": "Geth erroneously performed a 'shallow' copy when the precompiled `datacopy` (at `0x00...04`) was invoked. An attacker could deploy a contract that uses the shallow copy to corrupt the contents of the `RETURNDATA`, thus causing a consensus failure.", |
||||||
|
"links": [ |
||||||
|
"https://blog.ethereum.org/2020/11/12/geth_security_release/", |
||||||
|
"https://github.com/ethereum/go-ethereum/security/advisories/GHSA-69v6-xc2j-r2jf" |
||||||
|
], |
||||||
|
"introduced": "v1.9.7", |
||||||
|
"fixed": "v1.9.17", |
||||||
|
"published": "2020-11-12", |
||||||
|
"severity": "Critical", |
||||||
|
"CVE": "CVE-2020-26241", |
||||||
|
"check": "Geth\\/v1\\.9\\.(7|8|9|10|11|12|13|14|15|16).*$" |
||||||
|
}, |
||||||
|
{ |
||||||
|
"name": "Geth DoS via MULMOD", |
||||||
|
"uid": "GETH-2020-04", |
||||||
|
"summary": "A denial-of-service issue can be used to crash Geth nodes during block processing", |
||||||
|
"description": "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. \nThe crash was in the `uint256` library, where a buffer [underflowed](https://github.com/holiman/uint256/blob/4ce82e695c10ddad57215bdbeafb68b8c5df2c30/uint256.go#L442).\n\n\tif `d == 0`, `dLen` remains `0`\n\nand https://github.com/holiman/uint256/blob/4ce82e695c10ddad57215bdbeafb68b8c5df2c30/uint256.go#L451 will try to access index `[-1]`.\n\nThe `uint256` library was first merged in this [commit](https://github.com/ethereum/go-ethereum/commit/cf6674539c589f80031f3371a71c6a80addbe454), on 2020-06-08. \nExploiting this vulnerabilty would cause all vulnerable nodes to drop off the network. \n\nThe 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.\n \nIt 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.\n", |
||||||
|
"links": [ |
||||||
|
"https://blog.ethereum.org/2020/11/12/geth_security_release/", |
||||||
|
"https://github.com/ethereum/go-ethereum/security/advisories/GHSA-jm5c-rv3w-w83m", |
||||||
|
"https://github.com/holiman/uint256/releases/tag/v1.1.1", |
||||||
|
"https://github.com/holiman/uint256/pull/80", |
||||||
|
"https://github.com/ethereum/go-ethereum/pull/21368" |
||||||
|
], |
||||||
|
"introduced": "v1.9.16", |
||||||
|
"fixed": "v1.9.18", |
||||||
|
"published": "2020-11-12", |
||||||
|
"severity": "Critical", |
||||||
|
"CVE": "CVE-2020-26242", |
||||||
|
"check": "Geth\\/v1\\.9.(16|17).*$" |
||||||
|
}, |
||||||
|
{ |
||||||
|
"name": "LES Server DoS via GetProofsV2", |
||||||
|
"uid": "GETH-2020-05", |
||||||
|
"summary": "A DoS vulnerability can make a LES server crash.", |
||||||
|
"description": "A DoS vulnerability can make a LES server crash via malicious GetProofsV2 request from a connected LES client.\n\nThe vulnerability was patched in #21896.\n\nThis vulnerability only concern users explicitly running geth as a light server", |
||||||
|
"links": [ |
||||||
|
"https://github.com/ethereum/go-ethereum/security/advisories/GHSA-r33q-22hv-j29q", |
||||||
|
"https://github.com/ethereum/go-ethereum/pull/21896" |
||||||
|
], |
||||||
|
"introduced": "v1.8.0", |
||||||
|
"fixed": "v1.9.25", |
||||||
|
"published": "2020-12-10", |
||||||
|
"severity": "Medium", |
||||||
|
"CVE": "CVE-2020-26264", |
||||||
|
"check": "(Geth\\/v1\\.8\\.*)|(Geth\\/v1\\.9\\.\\d-.*)|(Geth\\/v1\\.9\\.1\\d-.*)|(Geth\\/v1\\.9\\.(20|21|22|23|24)-.*)$" |
||||||
|
}, |
||||||
|
{ |
||||||
|
"name": "SELFDESTRUCT-recreate consensus flaw", |
||||||
|
"uid": "GETH-2020-06", |
||||||
|
"introduced": "v1.9.4", |
||||||
|
"fixed": "v1.9.20", |
||||||
|
"summary": "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.\n\n- Tx 1:\n - `sender` invokes `caller`.\n - `caller` invokes `0xaa`. `0xaa` has 3 wei, does a self-destruct-to-self\n - `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)\n\n-Tx 2:\n - `sender` does a 5-wei call to 0xaa. No exec (since no code). \n\nIn 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. \n\nIt 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`.\n", |
||||||
|
"links": [ |
||||||
|
"https://github.com/ethereum/go-ethereum/security/advisories/GHSA-xw37-57qp-9mm4" |
||||||
|
], |
||||||
|
"published": "2020-12-10", |
||||||
|
"severity": "High", |
||||||
|
"CVE": "CVE-2020-26265", |
||||||
|
"check": "(Geth\\/v1\\.9\\.(4|5|6|7|8|9)-.*)|(Geth\\/v1\\.9\\.1\\d-.*)$" |
||||||
|
}, |
||||||
|
{ |
||||||
|
"name": "Not ready for London upgrade", |
||||||
|
"uid": "GETH-2021-01", |
||||||
|
"summary": "The client is not ready for the 'London' technical upgrade, and will deviate from the canonical chain when the London upgrade occurs (at block '12965000' around August 4, 2021.", |
||||||
|
"description": "At (or around) August 4, Ethereum will undergo a technical upgrade called 'London'. Clients not upgraded will fail to progress on the canonical chain.", |
||||||
|
"links": [ |
||||||
|
"https://github.com/ethereum/eth1.0-specs/blob/master/network-upgrades/mainnet-upgrades/london.md", |
||||||
|
"https://notes.ethereum.org/@timbeiko/ropsten-postmortem" |
||||||
|
], |
||||||
|
"introduced": "v1.10.1", |
||||||
|
"fixed": "v1.10.6", |
||||||
|
"published": "2021-07-22", |
||||||
|
"severity": "High", |
||||||
|
"check": "(Geth\\/v1\\.10\\.(1|2|3|4|5)-.*)$" |
||||||
|
}, |
||||||
|
{ |
||||||
|
"name": "RETURNDATA corruption via datacopy", |
||||||
|
"uid": "GETH-2021-02", |
||||||
|
"summary": "A consensus-flaw in the Geth EVM could cause a node to deviate from 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: mainnet splitting in two forks.\n\nAll Geth versions supporting the London hard fork are vulnerable (the bug is older than London), so all users should update.\n\nThis bug was exploited on Mainnet at block 13107518.\n\nCredits for the discovery go to @guidovranken (working for Sentnl during an audit of the Telos EVM) and reported via bounty@ethereum.org.", |
||||||
|
"links": [ |
||||||
|
"https://github.com/ethereum/go-ethereum/blob/master/docs/postmortems/2021-08-22-split-postmortem.md", |
||||||
|
"https://github.com/ethereum/go-ethereum/security/advisories/GHSA-9856-9gg9-qcmq", |
||||||
|
"https://github.com/ethereum/go-ethereum/releases/tag/v1.10.8" |
||||||
|
], |
||||||
|
"introduced": "v1.10.0", |
||||||
|
"fixed": "v1.10.8", |
||||||
|
"published": "2021-08-24", |
||||||
|
"severity": "High", |
||||||
|
"CVE": "CVE-2021-39137", |
||||||
|
"check": "(Geth\\/v1\\.10\\.(0|1|2|3|4|5|6|7)-.*)$" |
||||||
|
}, |
||||||
|
{ |
||||||
|
"name": "DoS via malicious `snap/1` request", |
||||||
|
"uid": "GETH-2021-03", |
||||||
|
"summary": "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.", |
||||||
|
"description": "The `snap/1` protocol handler contains two vulnerabilities related to the `GetTrieNodes` packet, which can be exploited to crash the node. Full details are available at the Github security [advisory](https://github.com/ethereum/go-ethereum/security/advisories/GHSA-59hh-656j-3p7v)", |
||||||
|
"links": [ |
||||||
|
"https://github.com/ethereum/go-ethereum/security/advisories/GHSA-59hh-656j-3p7v", |
||||||
|
"https://geth.ethereum.org/docs/vulnerabilities/vulnerabilities", |
||||||
|
"https://github.com/ethereum/go-ethereum/pull/23657" |
||||||
|
], |
||||||
|
"introduced": "v1.10.0", |
||||||
|
"fixed": "v1.10.9", |
||||||
|
"published": "2021-10-24", |
||||||
|
"severity": "Medium", |
||||||
|
"CVE": "CVE-2021-41173", |
||||||
|
"check": "(Geth\\/v1\\.10\\.(0|1|2|3|4|5|6|7|8)-.*)$" |
||||||
|
}, |
||||||
|
{ |
||||||
|
"name": "DoS via malicious p2p message", |
||||||
|
"uid": "GETH-2022-01", |
||||||
|
"summary": "A vulnerable node can crash via p2p messages sent from an attacker node, if running with non-default log options.", |
||||||
|
"description": "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. Full details are available at the Github security [advisory](https://github.com/ethereum/go-ethereum/security/advisories/GHSA-wjxw-gh3m-7pm5)", |
||||||
|
"links": [ |
||||||
|
"https://github.com/ethereum/go-ethereum/security/advisories/GHSA-wjxw-gh3m-7pm5", |
||||||
|
"https://geth.ethereum.org/docs/vulnerabilities/vulnerabilities", |
||||||
|
"https://github.com/ethereum/go-ethereum/pull/24507" |
||||||
|
], |
||||||
|
"introduced": "v1.10.0", |
||||||
|
"fixed": "v1.10.17", |
||||||
|
"published": "2022-05-11", |
||||||
|
"severity": "Low", |
||||||
|
"CVE": "CVE-2022-29177", |
||||||
|
"check": "(Geth\\/v1\\.10\\.(0|1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16)-.*)$" |
||||||
|
} |
||||||
|
] |
||||||
@ -0,0 +1,4 @@ |
|||||||
|
untrusted comment: signature from minisign secret key |
||||||
|
RWQk7Lo5TQgd+9DjD2nXoabMy0BkWSuMiePPOQ9rXlwzvjhRGzEtwPDK3YupbRT9/OmyykFLGHCzWTRKVtVfYqFHL07m0DOOnww= |
||||||
|
trusted comment: timestamp:1652258428 file:vulnerabilities.json |
||||||
|
jtud9mtIiBRWA+krlBf1WCHgRzkcuzeoe9YLjLfHLEUQosbs+Ru1oaxx+nhxmjKdSRFwhPy1yoV5j9+rw55yCg== |
||||||
@ -0,0 +1,113 @@ |
|||||||
|
--- |
||||||
|
title: Vulnerability disclosure |
||||||
|
sort_key: A |
||||||
|
--- |
||||||
|
|
||||||
|
## About disclosures |
||||||
|
|
||||||
|
In the software world, it is expected for security vulnerabilities to be immediately |
||||||
|
announced, thus giving operators an opportunity to take protective measure against |
||||||
|
attackers. |
||||||
|
|
||||||
|
Vulnerabilies typically take two forms: |
||||||
|
|
||||||
|
1. Vulnerabilies that, if exploited, would harm the software operator. In the case of |
||||||
|
go-ethereum, examples would be: |
||||||
|
- A bug that would allow remote reading or writing of OS files, or |
||||||
|
- Remote command execution, or |
||||||
|
- Bugs that would leak cryptographic keys |
||||||
|
2. Vulnerabilies that, if exploited, would harm the Ethereum mainnet. In the case of |
||||||
|
go-ethereum, examples would be: |
||||||
|
- Consensus vulnerabilities, which would cause a chain split, |
||||||
|
- Denial-of-service during block processing, whereby a malicious transaction could cause the geth-portion of the network to crash. |
||||||
|
- Denial-of-service via p2p networking, whereby portions of the network could be made |
||||||
|
inaccessible due to crashes or resource consumption. |
||||||
|
|
||||||
|
In most cases so far, vulnerabilities in `geth` have been of the second type, where the |
||||||
|
health of the network is a concern, rather than individual node operators. For such |
||||||
|
issues, we reserve the right to silently patch and ship fixes in new releases. |
||||||
|
|
||||||
|
### Why silent patches |
||||||
|
|
||||||
|
In the case of Ethereum, it takes a lot of time (weeks, months) to get node operators to |
||||||
|
update even to a scheduled hard fork. If we were to highlight that a release contains |
||||||
|
important consensus or DoS fixes, there is always a risk of someone trying to beat node |
||||||
|
operators to the punch, and exploit the vulnerability. Delaying a potential attack |
||||||
|
sufficiently to make the majority of node operators immune may be worth the temporary loss |
||||||
|
of transparency. |
||||||
|
|
||||||
|
The primary goal for the Geth team is the health of the Ethereum network as a whole, and |
||||||
|
the decision whether or not to publish details about a serious vulnerability boils down to |
||||||
|
minimizing the risk and/or impact of discovery and exploitation. |
||||||
|
|
||||||
|
At certain times, it's better to remain silent. This practice is also followed by other |
||||||
|
projects such as |
||||||
|
[Monero](https://www.getmonero.org/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html), |
||||||
|
[ZCash](https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/) |
||||||
|
and |
||||||
|
[Bitcoin](https://www.coindesk.com/the-latest-bitcoin-bug-was-so-bad-developers-kept-its-full-details-a-secret). |
||||||
|
|
||||||
|
### Public transparency |
||||||
|
|
||||||
|
As of November 2020, our policy going forward is: |
||||||
|
|
||||||
|
- If we silently fix a vulnerability and include the fix in release `X`, then, |
||||||
|
- After 4-8 weeks, we will disclose that `X` contained a security-fix. |
||||||
|
- After an additional 4-8 weeks, we will publish the details about the vulnerability. |
||||||
|
|
||||||
|
We hope that this provides sufficient balance between transparency versus the need for |
||||||
|
secrecy, and aids node operators and downstream projects in keeping up to date with what |
||||||
|
versions to run on their infrastructure. |
||||||
|
|
||||||
|
In keeping with this policy, we have taken inspiration from [Solidity bug disclosure](https://solidity.readthedocs.io/en/develop/bugs.html) - see below. |
||||||
|
|
||||||
|
## Disclosed vulnerabilities |
||||||
|
|
||||||
|
In this folder, you can find a JSON-formatted list |
||||||
|
([`vulnerabilities.json`](vulnerabilities.json)) of some of the known security-relevant |
||||||
|
vulnerabilities concerning `geth`. |
||||||
|
|
||||||
|
As of `geth` version `1.9.25`, geth has a built-in command to check whether it is affected |
||||||
|
by any publically disclosed vulnerability, using the command `geth version-check`. This |
||||||
|
command will fetch the latest json file (and the accompanying |
||||||
|
[signature-file](vulnerabilities.json.minisig), and cross-check the data against it's own |
||||||
|
version number. |
||||||
|
|
||||||
|
The file itself is hosted in the Github repository, on the `gh-pages`-branch. The list was |
||||||
|
started in November 2020, and covers mainly `v1.9.7` and forward. |
||||||
|
|
||||||
|
The JSON file of known vulnerabilities below is a list of objects, one for each |
||||||
|
vulnerability, with the following keys: |
||||||
|
|
||||||
|
- `name` |
||||||
|
- Unique name given to the vulnerability. |
||||||
|
- `uid` |
||||||
|
- Unique identifier of the vulnerability. Format `GETH-<year>-<sequential id>` |
||||||
|
- `summary` |
||||||
|
- Short description of the vulnerability. |
||||||
|
- `description` |
||||||
|
- Detailed description of the vulnerability. |
||||||
|
- `links` |
||||||
|
- List of relevant URLs with more detailed information (optional). |
||||||
|
- `introduced` |
||||||
|
- The first published Geth version that contained the vulnerability (optional). |
||||||
|
- `fixed` |
||||||
|
- The first published Geth version that did not contain the vulnerability anymore. |
||||||
|
- `published` |
||||||
|
- The date at which the vulnerability became known publicly (optional). |
||||||
|
- `severity` |
||||||
|
- Severity of the vulnerability: `low`, `medium`, `high`, `critical`. |
||||||
|
- Takes into account the severity of impact and likelihood of exploitation. |
||||||
|
- `check` |
||||||
|
- This field contains a regular expression, which can be used against the reported `web3_clientVersion` of a node. If the check |
||||||
|
matches, the node is with a high likelyhood affected by the vulnerability. |
||||||
|
- `CVE` |
||||||
|
- The assigned `CVE` identifier, if available (optional) |
||||||
|
|
||||||
|
### What about Github security advisories |
||||||
|
|
||||||
|
We prefer to not rely on Github as the only/primary publishing protocol for security |
||||||
|
advisories, but we plan to use the Github-advisory process as a second channel for |
||||||
|
disseminating vulnerability-information. |
||||||
|
|
||||||
|
Advisories published via Github can be accessed [here](https://github.com/ethereum/go-ethereum/security/advisories?state=published). |
||||||
Loading…
Reference in new issue