GHSA-p7mv-53f2-4cwj CometBFT Vote Extensions: Panic when receiving a Pre-commit with an invalid data

• Go github.com/cometbft/cometbft: >= 0.38.0, < 0.38.15 → fixed in 0.38.15

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) Affected versions: `>= 0.38.x`, unreleased `v1.x` and `main` development branches Affected users: Chain Builders + Maintainers, Validators Impact A 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 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 Qualification This 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. Patches The 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. Workarounds When 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] [abci-spec]: https://docs.cometbft.com/v0.38/spec/abci/abci++_basic_concepts [v0.38.15]: https://github.com/cometbft/cometbft/releases/tag/v0.38.15 Timeline • October 21, 2024, 3:26pm PST: Issue reported to the Cosmos Bug Bounty program • October 21, 2024, 3:41pm PST: Issue triaged by Amulet on-call, and distributed to Core team • October 29, 2024, 11:35pm PST: Core team completes validation of issue • October 30, 2024, 3:33am PST: Core team completes patch for issue • October 30, 2024, 5:09am PST: Amulet creates coordination plan; schedule for distribution • November 4, 2024, 8:00pm GMT: Pre-notification delivered • November 6, 2024, 8:00am GMT: Patch made available This issue was reported by 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 [email protected]. 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. For more information about CometBFT, see https://docs.cometbft.com/.