batch grants update

[Peartes]

Title: Add CLI Command to Update Treasury Configs & Fix Integration Test Gas Issue

Summary:
This PR introduces a new CLI command update-configs to batch update grant and fee configurations for the treasury contract. Additionally, it addresses an issue in the integration test TestUpdateTreasuryConfigsWithAALocalAndURL where setting an insufficient gas fee caused node container failures without meaningful error logs.

---

Changes Introduced:

1. New CLI Command: update-configs

   • Allows users to update treasury configurations via either a local file or a URL.
   • Handles grant and fee configurations.
   • Provides appropriate error handling for file parsing and HTTP requests.

2. Integration Test Updates:

   • Increased gas fees to avoid signature verification failures that previously caused SIGABRT crashes in Docker containers.

---

Implementation Details:

CLI Command: update-configs

Usage:

xion update-configs [contract_address] [config_path_or_url] --chain-id [CHAIN_ID] --from [KEY_NAME] --local -y

Features:

• Parses grant and fee configurations from either a local JSON file or a URL.
• Converts JSON authorization data to the proper Protobuf Any format.
• Sends batch update transactions to the treasury contract.
• Flags:
  • --local: Specifies that the config source is a local file instead of a URL.
  • Standard Cosmos transaction flags.

---

Integration Test: TestUpdateTreasuryConfigsWithAALocalAndURL

Issue Fixed:

• Previous runs on ARM64 architecture showed unexplained SIGABRT failures when gas fees were insufficient for signature verification.
• Tests were re-executed on AMD64 where errors were caught and addressed.

Key Fixes:

1. Increased gas fees in test cases:

   "--gas-prices", "1uxion", "--gas", "4000000",

[github-actions]

🔍 Vulnerabilities of xion:linux-amd64

📦 Image Reference xion:linux-amd64

digest	sha256:8296c887b3f5699e766bd2b3176c9df5d696c68138445e5d55a1bc32250a7105
vulnerabilities
platform	linux/amd64
size	116 MB
packages	344

📦 Base Image alpine:3.20

also known as	3.20.5
digest	sha256:a180ec8e5c7247c920c91508fa4ce86088946cc9e65f4aeb39091038bba88b0b
vulnerabilities

github.com/hashicorp/go-getter 1.7.1 (golang) pkg:golang/github.com/hashicorp/go-getter@1.7.1 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') Affected range >=1.5.9 <1.7.4 Fixed version 1.7.4 CVSS Score 9.8 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.043% EPSS Percentile 11th percentile Description When go-getter is performing a Git operation, go-getter will try to clone the given repository. If a Git reference is not passed along with the Git url, go-getter will then try to check the remote repository’s HEAD reference of its default branch by passing arguments to the Git binary on the host it is executing on. An attacker may format a Git URL in order to inject additional Git arguments to the Git call. Consumers of the go-getter library should evaluate the risk associated with these issues in the context of their go-getter usage and upgrade go-getter to 1.7.4 or later. Improper Neutralization of Special Elements used in a Command ('Command Injection') Affected range <1.7.5 Fixed version 1.7.5 CVSS Score 8.4 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:H EPSS Score 0.043% EPSS Percentile 11th percentile Description HashiCorp’s go-getter library can be coerced into executing Git update on an existing maliciously modified Git Configuration, potentially leading to arbitrary code execution. When go-getter is performing a Git operation, go-getter will try to clone the given repository in a specified destination. Cloning initializes a git config to the provided destination and if the repository needs to get updated go-getter will pull the new changes . An attacker may alter the Git config after the cloning step to set an arbitrary Git configuration to achieve code execution.

golang.org/x/crypto 0.11.0 (golang) pkg:golang/golang.org/x/crypto@0.11.0 Improper Authorization Affected range <0.31.0 Fixed version 0.31.0 CVSS Score 9.1 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N EPSS Score 0.045% EPSS Percentile 18th percentile Description Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/crypto@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance. Insufficient Verification of Data Authenticity Affected range <0.17.0 Fixed version 0.17.0 CVSS Score 5.9 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N EPSS Score 95.483% EPSS Percentile 100th percentile Description Summary Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it. Mitigations To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes. Warning: To take effect, both the client and server must support this countermeasure. As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available. Details The SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (*-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSH_MSG_EXT_INFO sent after the first message after SSH_MSG_NEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario. The attack works by an attacker injecting an arbitrary number of SSH_MSG_IGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSH_MSG_IGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange. In the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers. For more details see https://terrapin-attack.com. Impact This attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (*-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario.

golang.org/x/crypto 0.27.0 (golang) pkg:golang/golang.org/x/crypto@0.27.0 Improper Authorization Affected range <0.31.0 Fixed version 0.31.0 CVSS Score 9.1 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N EPSS Score 0.045% EPSS Percentile 18th percentile Description Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/crypto@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.

golang.org/x/net 0.12.0 (golang) pkg:golang/golang.org/x/net@0.12.0 Allocation of Resources Without Limits or Throttling Affected range <0.33.0 Fixed version 0.33.0 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.045% EPSS Percentile 18th percentile Description An attacker can craft an input to the Parse functions that would be processed non-linearly with respect to its length, resulting in extremely slow parsing. This could cause a denial of service. Uncontrolled Resource Consumption Affected range <0.17.0 Fixed version 0.17.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.590% EPSS Percentile 78th percentile Description A malicious HTTP/2 client which rapidly creates requests and immediately resets them can cause excessive server resource consumption. While the total number of requests is bounded by the http2.Server.MaxConcurrentStreams setting, resetting an in-progress request allows the attacker to create a new request while the existing one is still executing. With the fix applied, HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). New requests arriving when at the limit (which can only happen after the client has reset an existing, in-flight request) will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection. This issue is also fixed in golang.org/x/net/http2 for users manually configuring HTTP/2. The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This value may be adjusted using the golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams setting and the ConfigureServer function. Uncontrolled Resource Consumption Affected range <0.17.0 Fixed version 0.17.0 CVSS Score 6.9 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N EPSS Score 80.090% EPSS Percentile 99th percentile Description HTTP/2 Rapid reset attack The HTTP/2 protocol allows clients to indicate to the server that a previous stream should be canceled by sending a RST_STREAM frame. The protocol does not require the client and server to coordinate the cancellation in any way, the client may do it unilaterally. The client may also assume that the cancellation will take effect immediately when the server receives the RST_STREAM frame, before any other data from that TCP connection is processed. Abuse of this feature is called a Rapid Reset attack because it relies on the ability for an endpoint to send a RST_STREAM frame immediately after sending a request frame, which makes the other endpoint start working and then rapidly resets the request. The request is canceled, but leaves the HTTP/2 connection open. The HTTP/2 Rapid Reset attack built on this capability is simple: The client opens a large number of streams at once as in the standard HTTP/2 attack, but rather than waiting for a response to each request stream from the server or proxy, the client cancels each request immediately. The ability to reset streams immediately allows each connection to have an indefinite number of requests in flight. By explicitly canceling the requests, the attacker never exceeds the limit on the number of concurrent open streams. The number of in-flight requests is no longer dependent on the round-trip time (RTT), but only on the available network bandwidth. In a typical HTTP/2 server implementation, the server will still have to do significant amounts of work for canceled requests, such as allocating new stream data structures, parsing the query and doing header decompression, and mapping the URL to a resource. For reverse proxy implementations, the request may be proxied to the backend server before the RST_STREAM frame is processed. The client on the other hand paid almost no costs for sending the requests. This creates an exploitable cost asymmetry between the server and the client. Multiple software artifacts implementing HTTP/2 are affected. This advisory was originally ingested from the swift-nio-http2 repo advisory and their original conent follows. swift-nio-http2 specific advisory swift-nio-http2 is vulnerable to a denial-of-service vulnerability in which a malicious client can create and then reset a large number of HTTP/2 streams in a short period of time. This causes swift-nio-http2 to commit to a large amount of expensive work which it then throws away, including creating entirely new Channels to serve the traffic. This can easily overwhelm an EventLoop and prevent it from making forward progress. swift-nio-http2 1.28 contains a remediation for this issue that applies reset counter using a sliding window. This constrains the number of stream resets that may occur in a given window of time. Clients violating this limit will have their connections torn down. This allows clients to continue to cancel streams for legitimate reasons, while constraining malicious actors. Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Affected range <0.13.0 Fixed version 0.13.0 CVSS Score 6.1 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N EPSS Score 0.088% EPSS Percentile 39th percentile Description Text nodes not in the HTML namespace are incorrectly literally rendered, causing text which should be escaped to not be. This could lead to an XSS attack. Uncontrolled Resource Consumption Affected range <0.23.0 Fixed version 0.23.0 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L EPSS Score 0.044% EPSS Percentile 15th percentile Description An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.

github.com/cometbft/cometbft 0.38.12 (golang) pkg:golang/github.com/cometbft/cometbft@0.38.12 Improper Validation of Array Index Affected range >=0.38.0 <0.38.15 Fixed version 0.38.15 CVSS Score 8.3 CVSS Vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N Description 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 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 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, in particular the operation of vote extensions Patched v0.38 release 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 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. For more information about CometBFT, see https://docs.cometbft.com/. Insufficient Verification of Data Authenticity Affected range <0.38.17 Fixed version 0.38.17 Description Name: ASA-2025-002: Malicious peer can stall network by disseminating seemingly valid block parts Component: CometBFT Criticality: High (Catastrophic Impact; Possible Likelihood per ACMv1.2) Affected versions: <= v0.38.16, v1.0.0 Affected users: Validators, Full nodes, Users Description A bug was identified in the CometBFT validation of block part indices and the corresponding proof part indices that can lead to incorrect processing and dissemination of invalid parts, which in turn could lead to a network halt. Additional validation was added to prevent this condition from happening. Patches The new CometBFT releases v1.0.1 and v0.38.17 fix this issue. Unreleased code in the main branch is patched as well. Workarounds There are no known workarounds for this issue. If a node is producing these malicious proofs, the only mitigation is to upgrade CometBFT. After upgrading, the validators then will eventually conclude the correct value. Technical Deep-Dive When the next proposer creates a block, it is split into many block parts (64kB each). Each block part is then disseminated via p2p layer in a gossip fashion. The block part contains the following fields: type Part struct { Index uint32 `json:"index"` Bytes cmtbytes.HexBytes `json:"bytes"` Proof merkle.Proof `json:"proof"` } Index - represents the index of a block part Bytes - the actual content Proof - Merkle proof, which allows the receiving node to quickly verify that a Part is indeed a piece of the proposed block. The Proof contains the following fields: type Proof struct { Total int64 `json:"total"` // Total number of items. Index int64 `json:"index"` // Index of item to prove. LeafHash []byte `json:"leaf_hash"` // Hash of item value. Aunts [][]byte `json:"aunts,omitempty"` // Hashes from leaf's sibling to a root's child. } Note that the total number of leaves in the Merkle tree equals the number of parts in the proposed block. Previously, CometBFT did not validate the Index field and specifically that Part.Index must be equal to Part.Proof.Index. This leads to a condition where, it is possible to use the proof from a different part and CometBFT accept it, even though the proof proves the different part is a piece of the proposed block and not the part that the peer actually sent to us. This condition is problematic because: it would disseminate the invalid block part to its neighboring nodes (because it deemed it as correct) it would mark the block part as received and ask the neighboring nodes not to relay it in the future, making it impossible to receive the correct block part. To address this, CometBFT was patched to verify that Part.Index is equal to Part.Proof.Index, preventing the above condition. Timeline January 15, 2025, 12:12pm PST: Issue reported to the Cosmos Bug Bounty program January 15, 2025, 12:31pm PST: Issue triaged by Amulet on-call, and distributed to Core team January 27, 2025, 11:28pm PST: Core team completes validation of issue January 31, 2024, 2:15pm PST: Pre-notification delivered February 3rd, 2024, 9:00am UTC+4: Patch made available This issue was reported by unknown_feature to the Cosmos Bug Bounty Program on HackerOne on January 15, 2025. 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. 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/. Improper Check or Handling of Exceptional Conditions Affected range <0.38.17 Fixed version 0.38.17 CVSS Score 6.9 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N Description Name: ASA-2025-001: Malicious peer can disrupt node's ability to sync via blocksync Component: CometBFT Criticality: Medium (Considerable Impact; Possible Likelihood per ACMv1.2) Affected versions: <= v0.38.16, v1.0.0 Affected users: Validators, Full nodes Impact A malicious peer may be able to interfere with a node's ability to sync blocks with peers via the blocksync mechanism. In the blocksync protocol peers send their base and latest heights when they connect to a new node (A), which is syncing to the tip of a network. base acts as a lower ground and informs A that the peer only has blocks starting from height base. latest height informs A about the latest block in a network. Normally, nodes would only report increasing heights: B: {base: 100, latest: 1000} B: {base: 100, latest: 1001} B: {base: 100, latest: 1002} ... If B fails to provide the latest block, B is removed and the latest height (target height) is recalculated based on other nodes latest heights. The existing code hovewer doesn't check for the case where B first reports latest height X and immediately after height Y, where X > Y. For example: B: {base: 100, latest: 2000} B: {base: 100, latest: 1001} B: {base: 100, latest: 1002} ... A will be trying to catch up to 2000 indefinitely. Even if B disconnects, the latest height (target height) won't be recalculated because A "doesn't know where 2000" came from per see. Impact Qualification This condition requires the introduction of malicious code in the full node first reporting a non-existing latest height, then reporting lower latest height and nodes which are syncing using blocksync protocol. Patches The new CometBFT releases v1.0.1 and v0.38.17 fix this issue. Unreleased code in the main is patched as well. Workarounds When the operator notices blocksync is stuck, they can identify the peer from which that message with "invalid" height was received. This may require increasing the logging level of the blocksync module. This peer can then be subsequently banned at the p2p layer as a temporary mitigation. References If you have questions about Interchain security efforts, please reach out to our official communication channel at 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. For more information about CometBFT, see https://docs.cometbft.com/.

github.com/cosmos/cosmos-sdk 0.46.0-beta2.0.20230614103911-b3da8bb4e801 (golang) pkg:golang/github.com/cosmos/cosmos-sdk@0.46.0-beta2.0.20230614103911-b3da8bb4e801 Uncontrolled Resource Consumption Affected range <0.47.15 Fixed version 0.47.15 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N Description Summary ASA-2024-0012 Name: ASA-2024-0012, Transaction decoding may result in a stack overflow Component: Cosmos SDK Criticality: High (Considerable Impact, and Possible Likelihood per ACMv1.2) Affected versions: cosmos-sdk versions <= v0.50.10, <= v0.47.14 Affected users: Chain Builders + Maintainers, Validators, node operators ASA-2024-0013 Name: ASA-2024-0013: CosmosSDK: Transaction decoding may result in resource exhaustion Component: Cosmos SDK Criticality: High (Considerable Impact, and Possible Likelihood per ACMv1.2) Affected versions: cosmos-sdk versions <= v0.50.10, <= v0.47.14 Affected users: Chain Builders + Maintainers, Validators, node operators Impact ASA-2024-0012 When decoding a maliciously formed packet with a deeply-nested structure, it may be possible for a stack overflow to occur and result in a network halt. This was addressed by adding a recursion limit while decoding the packet. ASA-2024-0013 Nested messages in a transaction can consume exponential cpu and memory on UnpackAny calls. Themax_tx_bytes sets a limit for external TX but is not applied for internal messages emitted by wasm contracts or a malicious validator block. This may result in a node crashing due to resource exhaustion. This was addressed by adding additional validation to prevent this condition. Patches The issues above are resolved in Cosmos SDK versions v0.47.15 or v0.50.11. Please upgrade ASAP. Timeline for ASA-2024-0012 October 1, 2024, 12:29pm UTC: Issue reported to the Cosmos Bug Bounty program October 1, 2024, 2:47pm UTC: Issue triaged by Amulet on-call, and distributed to Core team December 9, 2024, 11:13am UTC: Core team completes patch for issue Dec 14, 2024,16:00 UTC: Pre-notification delivered Dec 16, 2024, 16:00 UTC: Patch made available This issue was reported to the Cosmos Bug Bounty Program on HackerOne on October 1, 2024. Timeline for ASA-2024-0013 October 19, 2024, 8:12pm UTC: Issue reported to the Cosmos Bug Bounty program October 19, 2024, 8:28pm UTC: Issue triaged by Amulet on-call, and distributed to Core team December 11, 2024, 3:31pm UTC: Core team completes patch for issue Dec 14, 2024, 16:00 UTC: Pre-notification delivered Dec 16, 2024, 16:00 UTC: Patch made available This issue was reported by LonelySloth to the Cosmos Bug Bounty Program on HackerOne on October 19, 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. 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. Improper Input Validation Affected range <=0.47.8 Fixed version 0.47.9 CVSS Score 6.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Description ASA-2024-003: Missing BlockedAddressed Validation in Vesting Module Component: Cosmos SDK Criticality: Low Affected Versions: Cosmos SDK versions <= 0.50.3; <= 0.47.8 Affected Users: Chain developers, Validator and Node operators Impact: Denial of Service Description A vulnerability was identified in the x/auth/vesting module, which can allow a user to create a periodic vesting account on a blocked address, for example a non-initialized module account. Additional validation was added to prevent creation of a periodic vesting account in this scenario. If this case is triggered, there is the potential for a chain halt if the uninitialized account in question is called by GetModuleAccount in Begin/EndBlock of a module. This combination of an uninitialized blocked module account is not common. Next Steps for Impacted Parties If your chain has uninitialized blocked module accounts, it is recommended to proactively initialize them, as they are often initialized during a chain migration or during init genesis. If you are a chain developer on an affected version of the Cosmos SDK, it is advised to update to the latest available version of the Cosmos SDK for your project. Once a patched version is available, it is recommended that network operators upgrade. A Github Security Advisory for this issue is available in the Cosmos-SDK repository. For more information about Cosmos SDK, see https://docs.cosmos.network/. This issue was found by Dongsam who reported it to the Cosmos Bug Bounty Program on HackerOne on January 30, 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. Addendum A variant trigger of this issue via the x/authz and x/feegrant modules was discovered by Richie who reported it to the Cosmos Bug Bounty Program on HackerOne on April 6th, 2024, and was subsequently fixed by the Cosmos SDK team on April 21st, 2024. The guidance for mitigating this additional variant is the same as the parent advisory, so it is suggested that all chains proactively initialize module accounts if they have not already done so. Improper Validation of Specified Index, Position, or Offset in Input Affected range <=0.47.8 Fixed version 0.47.9 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L Description ASA-2024-002: Default PrepareProposalHandler may produce invalid proposals when used with default SenderNonceMempool Component: Cosmos SDK Criticality: Medium Affected Versions: Cosmos SDK versions <= 0.50.3; <= 0.47.8 Affected Users: Chain developers, Validator and Node operators Impact: Denial of Service Summary When using the default PrepareProposalHandler and the default SenderNonceMempool, an issue was identified which may allow invalid blocks to be proposed when a single sender includes multiple transactions with non-sequential sequence numbers in certain conditions. If this state is reached, it can lead to a reduction in block production for a network. Next Steps for Impacted Parties If you are a chain developer on an affected version of the Cosmos SDK, it is advised to update to the latest available version of the Cosmos SDK for your project. Once a patched version is available, it is recommended that network operators upgrade. A Github Security Advisory for this issue is available in the Cosmos-SDK repository. For more information about Cosmos SDK, see https://docs.cosmos.network/. This issue was found by KonradStaniec, gitferry, SebastianElvis, and vitsalis who reported it to the Cosmos Bug Bounty Program on HackerOne on January 16, 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. Affected range <0.46 Fixed version 0.46 Description Component: Cosmovisor Criticality: Medium Affected Versions: Cosmovisor < v1.0.0 (distributed with Cosmos-SDK < 0.46) Affected Users: Validators and Node operators utilizing unsupported versions of Cosmovisor Impact: DOS, potential RCE on node depending on configuration An issue has been identified on unsupported versions of Cosmovisor which may result in a Denial of Service or Remote Code Execution path depending on configuration for a node or validator using the vulnerable version to manage their node. If a validator is utilizing an affected version of Cosmovisor with DAEMON_ALLOW_DOWNLOAD_BINARIES set to true, a non-default configuration, it may be possible for an attacker to trigger a Remote Code Execution path as well on the host. In this configuration it is recommended to immediately stop use of the DAEMON_ALLOW_DOWNLOAD_BINARIES feature, and then proceed with an upgrade of Cosmovisor. It is recommended that all validators utilizing unsupported versions of Cosmovisor to upgrade to the latest supported versions immediately. If you are utilizing a forked version of Cosmos-SDK, it is recommended to stop use of Cosmovisor until it is possible to update to a supported version of Cosmovisor, whether through your project’s fork, or directly compiled from the Cosmos-SDK. At the time of this advisory, the latest version of Cosmovisor is v1.5.0. Additionally, the Amulet team recommends that developers building chains powered by Cosmos-SDK share this advisory with validators and node operators to ensure this information is available to all impacted parties within their ecosystems. For more information about Cosmovisor, see https://docs.cosmos.network/main/tooling/cosmovisor This issue was discovered by Maxwell Dulin and Nathan Kirkland, who reported it to the Cosmos Bug Bounty Program. 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. How to tell if I am affected? Running the following command will output whether your cosmovisor version is vulnerable to this issue or not. Vulnerable to this issue: strings ./cosmovisor | grep -q "NEEDED at" && echo "vulnerable" || echo "NOT vulnerable" vulnerable NOT vulnerable to this issue: strings ./cosmovisor_new | grep -q "NEEDED at" && echo "vulnerable" || echo "NOT vulnerable" NOT vulnerable A Note from Amulet on the Security Advisory Process In the interest of timely resolution of this issue for validators and node operators, the Amulet team has chosen to use existing processes and resources for distributing security advisories within the Cosmos and Interchain Ecosystems. Stay tuned as we implement an improved, more robust security advisory distribution system that will provide equitable access to information about security issues in the Interchain Stack. Incomplete Internal State Distinction Affected range <=0.47.9 Fixed version 0.47.10 Description ASA-2024-005: Potential slashing evasion during re-delegation Component: Cosmos SDK Criticality: Low Affected Versions: Cosmos SDK versions <= 0.50.4; <= 0.47.9 Affected Users: Chain developers, Validator and Node operators Impact: Slashing Evasion Summary An issue was identified in the slashing mechanism that may allow for the evasion of slashing penalties during a slashing event. If a delegation contributed to byzantine behavior of a validator, and the validator has not yet been slashed, it may be possible for that delegation to evade a pending slashing penalty through re-delegation behavior. Additional validation logic was added to restrict this behavior. Next Steps for Impacted Parties If you are a chain developer on an affected version of the Cosmos SDK, it is advised to update to the latest available version of the Cosmos SDK for your project. Once a patched version is available, it is recommended that network operators upgrade. A Github Security Advisory for this issue is available in the Cosmos-SDK repository. For more information about Cosmos SDK, see https://docs.cosmos.network/. This issue was found by cat shark (Khanh) who reported it to the Cosmos Bug Bounty Program on HackerOne on December 6, 2023. 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. Affected range <0.46.13 Fixed version 0.46.13 Description The cosmos-sdk module is affected by the vulnerability codenamed "Barberry".

google.golang.org/grpc 1.56.2 (golang) pkg:golang/google.golang.org/grpc@1.56.2 Affected range <1.56.3 Fixed version 1.56.3 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Description Impact In affected releases of gRPC-Go, it is possible for an attacker to send HTTP/2 requests, cancel them, and send subsequent requests, which is valid by the HTTP/2 protocol, but would cause the gRPC-Go server to launch more concurrent method handlers than the configured maximum stream limit. Patches This vulnerability was addressed by #6703 and has been included in patch releases: 1.56.3, 1.57.1, 1.58.3. It is also included in the latest release, 1.59.0. Along with applying the patch, users should also ensure they are using the grpc.MaxConcurrentStreams server option to apply a limit to the server's resources used for any single connection. Workarounds None. References #6703 Uncontrolled Resource Consumption Affected range <1.56.3 Fixed version 1.56.3 CVSS Score 6.9 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N EPSS Score 80.090% EPSS Percentile 99th percentile Description HTTP/2 Rapid reset attack The HTTP/2 protocol allows clients to indicate to the server that a previous stream should be canceled by sending a RST_STREAM frame. The protocol does not require the client and server to coordinate the cancellation in any way, the client may do it unilaterally. The client may also assume that the cancellation will take effect immediately when the server receives the RST_STREAM frame, before any other data from that TCP connection is processed. Abuse of this feature is called a Rapid Reset attack because it relies on the ability for an endpoint to send a RST_STREAM frame immediately after sending a request frame, which makes the other endpoint start working and then rapidly resets the request. The request is canceled, but leaves the HTTP/2 connection open. The HTTP/2 Rapid Reset attack built on this capability is simple: The client opens a large number of streams at once as in the standard HTTP/2 attack, but rather than waiting for a response to each request stream from the server or proxy, the client cancels each request immediately. The ability to reset streams immediately allows each connection to have an indefinite number of requests in flight. By explicitly canceling the requests, the attacker never exceeds the limit on the number of concurrent open streams. The number of in-flight requests is no longer dependent on the round-trip time (RTT), but only on the available network bandwidth. In a typical HTTP/2 server implementation, the server will still have to do significant amounts of work for canceled requests, such as allocating new stream data structures, parsing the query and doing header decompression, and mapping the URL to a resource. For reverse proxy implementations, the request may be proxied to the backend server before the RST_STREAM frame is processed. The client on the other hand paid almost no costs for sending the requests. This creates an exploitable cost asymmetry between the server and the client. Multiple software artifacts implementing HTTP/2 are affected. This advisory was originally ingested from the swift-nio-http2 repo advisory and their original conent follows. swift-nio-http2 specific advisory swift-nio-http2 is vulnerable to a denial-of-service vulnerability in which a malicious client can create and then reset a large number of HTTP/2 streams in a short period of time. This causes swift-nio-http2 to commit to a large amount of expensive work which it then throws away, including creating entirely new Channels to serve the traffic. This can easily overwhelm an EventLoop and prevent it from making forward progress. swift-nio-http2 1.28 contains a remediation for this issue that applies reset counter using a sliding window. This constrains the number of stream resets that may occur in a given window of time. Clients violating this limit will have their connections torn down. This allows clients to continue to cancel streams for legitimate reasons, while constraining malicious actors.

github.com/cometbft/cometbft 0.38.0-rc3 (golang) pkg:golang/github.com/cometbft/cometbft@0.38.0-rc3 Insufficient Verification of Data Authenticity Affected range <0.38.17 Fixed version 0.38.17 Description Name: ASA-2025-002: Malicious peer can stall network by disseminating seemingly valid block parts Component: CometBFT Criticality: High (Catastrophic Impact; Possible Likelihood per ACMv1.2) Affected versions: <= v0.38.16, v1.0.0 Affected users: Validators, Full nodes, Users Description A bug was identified in the CometBFT validation of block part indices and the corresponding proof part indices that can lead to incorrect processing and dissemination of invalid parts, which in turn could lead to a network halt. Additional validation was added to prevent this condition from happening. Patches The new CometBFT releases v1.0.1 and v0.38.17 fix this issue. Unreleased code in the main branch is patched as well. Workarounds There are no known workarounds for this issue. If a node is producing these malicious proofs, the only mitigation is to upgrade CometBFT. After upgrading, the validators then will eventually conclude the correct value. Technical Deep-Dive When the next proposer creates a block, it is split into many block parts (64kB each). Each block part is then disseminated via p2p layer in a gossip fashion. The block part contains the following fields: type Part struct { Index uint32 `json:"index"` Bytes cmtbytes.HexBytes `json:"bytes"` Proof merkle.Proof `json:"proof"` } Index - represents the index of a block part Bytes - the actual content Proof - Merkle proof, which allows the receiving node to quickly verify that a Part is indeed a piece of the proposed block. The Proof contains the following fields: type Proof struct { Total int64 `json:"total"` // Total number of items. Index int64 `json:"index"` // Index of item to prove. LeafHash []byte `json:"leaf_hash"` // Hash of item value. Aunts [][]byte `json:"aunts,omitempty"` // Hashes from leaf's sibling to a root's child. } Note that the total number of leaves in the Merkle tree equals the number of parts in the proposed block. Previously, CometBFT did not validate the Index field and specifically that Part.Index must be equal to Part.Proof.Index. This leads to a condition where, it is possible to use the proof from a different part and CometBFT accept it, even though the proof proves the different part is a piece of the proposed block and not the part that the peer actually sent to us. This condition is problematic because: it would disseminate the invalid block part to its neighboring nodes (because it deemed it as correct) it would mark the block part as received and ask the neighboring nodes not to relay it in the future, making it impossible to receive the correct block part. To address this, CometBFT was patched to verify that Part.Index is equal to Part.Proof.Index, preventing the above condition. Timeline January 15, 2025, 12:12pm PST: Issue reported to the Cosmos Bug Bounty program January 15, 2025, 12:31pm PST: Issue triaged by Amulet on-call, and distributed to Core team January 27, 2025, 11:28pm PST: Core team completes validation of issue January 31, 2024, 2:15pm PST: Pre-notification delivered February 3rd, 2024, 9:00am UTC+4: Patch made available This issue was reported by unknown_feature to the Cosmos Bug Bounty Program on HackerOne on January 15, 2025. 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. 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/. Improper Check or Handling of Exceptional Conditions Affected range <0.38.17 Fixed version 0.38.17 CVSS Score 6.9 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N Description Name: ASA-2025-001: Malicious peer can disrupt node's ability to sync via blocksync Component: CometBFT Criticality: Medium (Considerable Impact; Possible Likelihood per ACMv1.2) Affected versions: <= v0.38.16, v1.0.0 Affected users: Validators, Full nodes Impact A malicious peer may be able to interfere with a node's ability to sync blocks with peers via the blocksync mechanism. In the blocksync protocol peers send their base and latest heights when they connect to a new node (A), which is syncing to the tip of a network. base acts as a lower ground and informs A that the peer only has blocks starting from height base. latest height informs A about the latest block in a network. Normally, nodes would only report increasing heights: B: {base: 100, latest: 1000} B: {base: 100, latest: 1001} B: {base: 100, latest: 1002} ... If B fails to provide the latest block, B is removed and the latest height (target height) is recalculated based on other nodes latest heights. The existing code hovewer doesn't check for the case where B first reports latest height X and immediately after height Y, where X > Y. For example: B: {base: 100, latest: 2000} B: {base: 100, latest: 1001} B: {base: 100, latest: 1002} ... A will be trying to catch up to 2000 indefinitely. Even if B disconnects, the latest height (target height) won't be recalculated because A "doesn't know where 2000" came from per see. Impact Qualification This condition requires the introduction of malicious code in the full node first reporting a non-existing latest height, then reporting lower latest height and nodes which are syncing using blocksync protocol. Patches The new CometBFT releases v1.0.1 and v0.38.17 fix this issue. Unreleased code in the main is patched as well. Workarounds When the operator notices blocksync is stuck, they can identify the peer from which that message with "invalid" height was received. This may require increasing the logging level of the blocksync module. This peer can then be subsequently banned at the p2p layer as a temporary mitigation. References If you have questions about Interchain security efforts, please reach out to our official communication channel at 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. For more information about CometBFT, see https://docs.cometbft.com/.

golang.org/x/net 0.29.0 (golang) pkg:golang/golang.org/x/net@0.29.0 Allocation of Resources Without Limits or Throttling Affected range <0.33.0 Fixed version 0.33.0 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.045% EPSS Percentile 18th percentile Description An attacker can craft an input to the Parse functions that would be processed non-linearly with respect to its length, resulting in extremely slow parsing. This could cause a denial of service.

cosmossdk.io/x/tx 0.9.1 (golang) pkg:golang/cosmossdk.io/x/tx@0.9.1 Uncontrolled Resource Consumption Affected range <0.13.7 Fixed version 0.13.7 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N Description Summary ASA-2024-0012 Name: ASA-2024-0012, Transaction decoding may result in a stack overflow Component: Cosmos SDK Criticality: High (Considerable Impact, and Possible Likelihood per ACMv1.2) Affected versions: cosmos-sdk versions <= v0.50.10, <= v0.47.14 Affected users: Chain Builders + Maintainers, Validators, node operators ASA-2024-0013 Name: ASA-2024-0013: CosmosSDK: Transaction decoding may result in resource exhaustion Component: Cosmos SDK Criticality: High (Considerable Impact, and Possible Likelihood per ACMv1.2) Affected versions: cosmos-sdk versions <= v0.50.10, <= v0.47.14 Affected users: Chain Builders + Maintainers, Validators, node operators Impact ASA-2024-0012 When decoding a maliciously formed packet with a deeply-nested structure, it may be possible for a stack overflow to occur and result in a network halt. This was addressed by adding a recursion limit while decoding the packet. ASA-2024-0013 Nested messages in a transaction can consume exponential cpu and memory on UnpackAny calls. Themax_tx_bytes sets a limit for external TX but is not applied for internal messages emitted by wasm contracts or a malicious validator block. This may result in a node crashing due to resource exhaustion. This was addressed by adding additional validation to prevent this condition. Patches The issues above are resolved in Cosmos SDK versions v0.47.15 or v0.50.11. Please upgrade ASAP. Timeline for ASA-2024-0012 October 1, 2024, 12:29pm UTC: Issue reported to the Cosmos Bug Bounty program October 1, 2024, 2:47pm UTC: Issue triaged by Amulet on-call, and distributed to Core team December 9, 2024, 11:13am UTC: Core team completes patch for issue Dec 14, 2024,16:00 UTC: Pre-notification delivered Dec 16, 2024, 16:00 UTC: Patch made available This issue was reported to the Cosmos Bug Bounty Program on HackerOne on October 1, 2024. Timeline for ASA-2024-0013 October 19, 2024, 8:12pm UTC: Issue reported to the Cosmos Bug Bounty program October 19, 2024, 8:28pm UTC: Issue triaged by Amulet on-call, and distributed to Core team December 11, 2024, 3:31pm UTC: Core team completes patch for issue Dec 14, 2024, 16:00 UTC: Pre-notification delivered Dec 16, 2024, 16:00 UTC: Patch made available This issue was reported by LonelySloth to the Cosmos Bug Bounty Program on HackerOne on October 19, 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. 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.

cosmossdk.io/math 1.0.1 (golang) pkg:golang/cosmossdk.io/math@1.0.1 Integer Overflow or Wraparound Affected range <=1.3.0 Fixed version 1.4.0 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N Description Name: ASA-2024-010: Mismatched bit-length in sdk.Int and sdk.Dec can lead to panic Component: Cosmos SDK / Math Criticality: High (Considerable Impact, and Possible Likelihood per ACMv1.2) Affected versions: cosmossdk.io/math package versions <= math/v1.3.0 Affected users: Chain Builders + Maintainers, Validators Impact The bit-length in sdk.Int and sdk.Dec are not aligned, which may present a possible panic condition when interacting with Dec types in an Int context. This issue was resolved by aligning the max size between the data types in the cosmossdk.io/math package. This issue impacts consumers of the cosmossdk.io/math, which includes popular modules including IBC-Go and tokenfactory (permissionless). If your chain interacts with APIs in the cosmossdk.io/math package, or utilizes a module that consumes this library, it is advised to update to the latest version at the time of the patch release by updating your project's go.mod dependency for cosmossdk.io/math. The patch can be applied without a hard-fork, and with a version bump in a chain's go.mod file like the following: go.mod - cosmossdk.io/math v1.3.0 + cosmossdk.io/math v1.4.0 [!NOTE] When on a lower version than cosmossdk.io/math v1.3.0, please do a coordinated upgrade before upgrading to >= 1.3.0 Patches The new release of cosmossdk.io/math v1.4.0 resolves this issue. Chains that utilize the cosmossdk.io/math library or modules that utilize the cosmossdk.io/math library should update to avoid this condition. Timeline October 31, 2024, 6:55pm UTC: Issue reported to the Cosmos Bug Bounty program October 31, 2024, 8:56pm UTC: Issue triaged by Amulet on-call, and distributed to Core team Nov 15, 2024, 2:12am PST: Core team completes patch for issue Nov 19, 2024, 8:00am PST / 16:00 GMT: Pre-notification delivered Nov 20, 2024, 8:00am PST / 16:00 GMT: Patch made available This issue was reported by LonelySloth to the Cosmos Bug Bounty Program on HackerOne on October 31, 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. 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.

github.com/cosmwasm/wasmvm/v2 2.1.2 (golang) pkg:golang/github.com/cosmwasm/wasmvm@2.1.2#v2 Affected range >=2.1.0 <2.1.3 Fixed version 2.1.3 Description CWA-2024-008 Severity Medium (Moderate + Likely)1 Affected versions: wasmvm >= 2.1.0, < 2.1.3 wasmvm >= 2.0.0, < 2.0.4 wasmvm < 1.5.5 cosmwasm-vm >= 2.1.0, < 2.1.4 cosmwasm-vm >= 2.0.0, < 2.0.7 cosmwasm-vm < 1.5.8 Patched versions: wasmvm 1.5.5, 2.0.4, 2.1.3 cosmwasm-vm 1.5.8, 2.0.7, 2.1.4 Description of the bug (Blank for now. We'll add more detail once chains had a chance to upgrade.) Patch 1.5: CosmWasm/cosmwasm@edcdbc5 2.0: CosmWasm/cosmwasm@f63429c 2.1: CosmWasm/cosmwasm@108e7dc Applying the patch The patch will be shipped in releases of wasmvm. You can update more or less as follows: Check the current wasmvm version: go list -m github.com/CosmWasm/wasmvm Bump the github.com/CosmWasm/wasmvm dependency in your go.mod to 1.5.5, 2.0.4, 2.1.3 depending on which minor version you are; go mod tidy; commit. If you use the static libraries libwasmvm_muslc.aarch64.a/libwasmvm_muslc.x86_64.a, update them accordingly. Check the updated wasmvm version: go list -m github.com/CosmWasm/wasmvm and ensure you see 1.5.5, 2.0.4, 2.1.3. Follow your regular practices to deploy chain upgrades. To double check if the correct library version is loaded at runtime, use this query: <appd> query wasm libwasmvm-version. It must show 1.5.5, 2.0.4 or 2.1.3. The patch is consensus breaking and requires a coordinated upgrade. Acknowledgement This issue was found by meadow101 who reported it to the Cosmos Bug Bounty Program on HackerOne. 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. Timeline 2024-08-22: Confio receives a report through the Cosmos bug bounty program maintained by Amulet. 2024-08-23: Confio security contributors confirm the report. 2024-09-09: Confio developed the patch internally. 2024-09-23: Patch is released. Affected range >=2.1.0 <2.1.3 Fixed version 2.1.3 Description CWA-2024-007 Severity Medium (Moderate + Likely)1 Affected versions: wasmvm >= 2.1.0, < 2.1.3 wasmvm >= 2.0.0, < 2.0.4 wasmvm < 1.5.5 cosmwasm-vm >= 2.1.0, < 2.1.4 cosmwasm-vm >= 2.0.0, < 2.0.7 cosmwasm-vm < 1.5.8 Patched versions: wasmvm 1.5.5, 2.0.4, 2.1.3 cosmwasm-vm 1.5.8, 2.0.7, 2.1.4 Description of the bug (Blank for now. We'll add more detail once chains had a chance to upgrade.) Patch 1.5: CosmWasm/cosmwasm@16eabd6 2.0: CosmWasm/cosmwasm@0e70bd8 2.1: CosmWasm/cosmwasm@f5bf24f Applying the patch The patch will be shipped in releases of wasmvm. You can update more or less as follows: Check the current wasmvm version: go list -m github.com/CosmWasm/wasmvm Bump the github.com/CosmWasm/wasmvm dependency in your go.mod to 1.5.5, 2.0.4, 2.1.3 depending on which minor version you are; go mod tidy; commit. If you use the static libraries libwasmvm_muslc.aarch64.a/libwasmvm_muslc.x86_64.a, update them accordingly. Check the updated wasmvm version: go list -m github.com/CosmWasm/wasmvm and ensure you see 1.5.5, 2.0.4, 2.1.3. Follow your regular practices to deploy chain upgrades. To double check if the correct library version is loaded at runtime, use this query: <appd> query wasm libwasmvm-version. It must show 1.5.5, 2.0.4 or 2.1.3. The patch is consensus breaking and requires a coordinated upgrade. Acknowledgement This issue was found by meadow101 who reported it to the Cosmos Bug Bounty Program on HackerOne. 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. Timeline 2024-08-28: Confio receives a report through the Cosmos bug bounty program maintained by Amulet. 2024-08-30: Confio security contributors confirm the report. 2024-09-02: Confio developed the patch internally. 2024-09-23: Patch is released.

github.com/dvsekhvalnov/jose2go 1.5.0 (golang) pkg:golang/github.com/dvsekhvalnov/jose2go@1.5.0 Uncontrolled Resource Consumption Affected range <1.5.1-0.20231206184617-48ba0b76bc88 Fixed version 1.5.1-0.20231206184617-48ba0b76bc88 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L Description An attacker controlled input of a PBES2 encrypted JWE blob can have a very large p2c value that, when decrypted, produces a denial-of-service. Affected range <1.6.0 Fixed version 1.6.0 EPSS Score 0.043% EPSS Percentile 11th percentile Description The jose2go component before 1.6.0 for Go allows attackers to cause a denial of service (CPU consumption) via a large p2c (aka PBES2 Count) value.

google.golang.org/protobuf 1.31.0 (golang) pkg:golang/google.golang.org/protobuf@1.31.0 Loop with Unreachable Exit Condition ('Infinite Loop') Affected range <1.33.0 Fixed version 1.33.0 CVSS Score 6.6 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U EPSS Score 0.045% EPSS Percentile 18th percentile Description The protojson.Unmarshal function can enter an infinite loop when unmarshaling certain forms of invalid JSON. This condition can occur when unmarshaling into a message which contains a google.protobuf.Any value, or when the UnmarshalOptions.DiscardUnknown option is set.

github.com/cosmwasm/wasmd 0.53.0 (golang) pkg:golang/github.com/cosmwasm/wasmd@0.53.0 Affected range <0.53.2 Fixed version 0.53.2 Description CWA-2024-009 Severity Low (Marginal + Likely)1 Affected versions: wasmd < 0.53.1 Patched versions: wasmd 0.53.2 (please note that wasmd 0.53.1 is broken and must not be used) Description of the bug (Blank for now. We'll add more detail once chains had a chance to upgrade.) Mitigations Apart from upgrading, it is recommended to not open the gRPC and REST APIs of validator nodes to the public internet. Use isolated and resource-constrained environments for running separate public RPC nodes instead. These can then easily be thrown away and replaced with new instances in case of problems. Applying the patch Official Wasmd patch The patch will be shipped in a wasmd release. You will also have to update libwasmvm if you build statically. If you already use the latest / close to latest wasmd, you can update more or less as follows: Check the current wasmd version: go list -m github.com/CosmWasm/wasmd Bump the github.com/CosmWasm/wasmd dependency in your go.mod to 0.53.2 (Cosmos SDK 0.50 compatible); go mod tidy; commit. If you use the static libraries libwasmvm_muslc.aarch64.a/libwasmvm_muslc.x86_64.a, make sure that you use the same version as your wasmvm version. Check the updated wasmd version: go list -m github.com/CosmWasm/wasmd and ensure you see 0.53.2. Follow your regular practices to deploy chain upgrades. To double check if the correct library version is loaded at runtime, use this query: <appd> query wasm libwasmvm-version. It must show 2.1.4. The patch is not consensus breaking if you are already using wasmvm 2.1.3. If you are instead using wasmvm 2.1.2, then upgrading to 2.1.4 includes the consensus breaking changes of 2.1.3. DIY Patch If you are unable to upgrade to the latest version, you can backport the wasmd patch to your version. The patch is available at Wasmd 0.53.2. However, if you are on an older version of wasmd, you will also be using a different version of wasmvm. We provide the required patches for wasmvm in versions 2.1.4, 2.0.5, 1.5.6. To upgrade using this method: Check the current wasmvm version: go list -m github.com/CosmWasm/wasmvm and upgrade to the closest patched version. Bump the github.com/CosmWasm/wasmvm dependency in your go.mod to the closest compatible patched version (either 2.1.4, 2.0.5 or 1.5.6); go mod tidy; commit. Apply the patch linked above to your version of wasmd. If you use the static libraries libwasmvm_muslc.aarch64.a/libwasmvm_muslc.x86_64.a, make sure that you use the same version as your wasmvm version. Follow your regular practices to deploy chain upgrades. To double check if the correct library version is loaded at runtime, use this query: <appd> query wasm libwasmvm-version. It must show 2.1.4, 2.0.5 or 1.5.6 and must be the same as the wasmvm version in your go.sum. The patch is not consensus breaking as long as you were using the previous patch version of wasmvm before. Acknowledgement This issue was found by meadow101 who reported it to the Cosmos Bug Bounty Program on HackerOne. 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. Timeline 2024-09-25: Confio receives a report through the Cosmos bug bounty program maintained by Amulet. 2024-09-30: Confio security contributors confirm the report. 2024-11-21: Confio developed the patch internally. 2024-12-06: Patch release is pre-announced through notification lists. 2024-12-10: Patch released.

Footnotes

1. following Amulet's Severity Classification Framework ACMv1: https://github.com/interchainio/security/blob/e0227a1fb4059144aab4f6003eeee7f09912db3a/resources/CLASSIFICATION_MATRIX.md ↩ ↩² ↩³

[2xburnt]

I find it really confusing when a PR is labelled WIP, also not crazy about seeing all the "WIP" branches in our history it looks like we just merge in incomplete PR's regularly

if it is a draft use the functionality in github branches for drafts

if it is ready to be merged take WIP out of the title

[Peartes]

I find it really confusing when a PR is labelled WIP, also not crazy about seeing all the "WIP" branches in our history it looks like we just merge in incomplete PR's regularly

if it is a draft use the functionality in github branches for drafts

if it is ready to be merged take WIP out of the title

Sorry about the WIP. It's ready to be reviewed

[justinbarry]

@Peartes Could you put together a quick demo video of this feature?

[justinbarry]

Will this disappear when the branch goes away?