GHSA-p7mv-53f2-4cwj CometBFT Vote Extensions: Panic when receiving a Pre-commit with an invalid data
Name: ASA-2024-011: Vote Extensions: Panic when receiving a Pre-commit with an invalid data
Component: CometBFT
Criticality: High (Considerable Impact, and Possible Likelihood per [ACMv1.2](https://github.com/interchainio/security/blob/main/resources/CLASSIFICATION_MATRIX.md))
Affected versions: `>= 0.38.x`, unreleased `v1.x` and `main` development branches
Affected users: Chain Builders + Maintainers, ValidatorsImpactA CometBFT node running in a network with [vote extensions][abci-spec] enabled could produce an invalid `Vote` message and send it to its peers. The invalid field of the `Vote` message is the `ValidatorIndex`, which identifies the sender in the `ValidatorSet` running that height of consensus. This field is ordinarily verified in the processing of `Vote` messages, but it turns out that in the case of a `Vote` message of type `Precommit` and for a non-`nil` `BlockID`, [a logic was introduced](https://github.com/cometbft/cometbft/blame/46621a87064b2ae235e122e66d9b22417b3aa35e/internal/consensus/state.go#L2357-L2364) before this ordinary verification to handle the attached vote extension. This introduced logic (not present in releases prior to `0.38.x`) does not double-check the validity of the `ValidatorIndex` field. The result is a panic in the execution of the node receiving and processing such message.Impact QualificationThis condition requires the introduction of malicious code in the full node sending this `Vote` message to its peers. Namely, nodes running upstream code cannot produce invalid `Vote` messages, with non-existing `ValidatorIndex`. Moreover, networks utilizing default behavior, where vote extensions are not enabled, are not affected by this issue.PatchesThe new CometBFT release [`v0.38.15`][v0.38.15] fixes this issue.Unreleased code in the `main` and `v1.x` branches, and experimental code in the `v0.38-experimental` and `v1.x-experimental` branches are patched as well.WorkaroundsWhen the consensus code panics after receiving an invalid `Vote` message, the operator can identify the peer from which that message was received. This may require increasing the logging level of the `consensus` module. This peer can then be subsequently banned at the p2p layer as a temporary mitigation.References[ABCI spec][abci-spec], in particular the operation of vote extensions[Patched v0.38 release][v0.38.15]TimelineOctober 21, 2024, 3:26pm PST: Issue reported to the Cosmos Bug Bounty programOctober 21, 2024, 3:41pm PST: Issue triaged by Amulet on-call, and distributed to Core teamOctober 29, 2024, 11:35pm PST: Core team completes validation of issueOctober 30, 2024, 3:33am PST: Core team completes patch for issueOctober 30, 2024, 5:09am PST: Amulet creates coordination plan; schedule for distributionNovember 4, 2024, 8:00pm GMT: Pre-notification deliveredNovember 6, 2024, 8:00am GMT: Patch made availableThis issue was reported by [corverroos](https://github.com/corverroos) to the Cosmos Bug Bounty Program on HackerOne on October 21, 2024. If you believe you have found a bug in the Interchain Stack or would like to contribute to the program by reporting a bug, please see https://hackerone.com/cosmos.If you have questions about Interchain security efforts, please reach out to our official communication channel at [security@interchain.io](mailto:security@interchain.io).  For more information about the Interchain Foundation’s engagement with Amulet, and to sign up for security notification emails, please see https://github.com/interchainio/security.A Github Security Advisory for this issue is available in the CometBFT [repository](https://github.com/cometbft/cometbft/security/advisories/GHSA-p7mv-53f2-4cwj). For more information about CometBFT, see https://docs.cometbft.com/.
CVSS v4.0 score: 8.3