-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add in authz stargate query #209
Conversation
🔍 Vulnerabilities of
|
digest | sha256:cac310083600440eb866e6ab18af2f08a7bafd4e89f5fe1709d248b933ae1865 |
vulnerabilities | |
size | 70 MB |
packages | 218 |
📦 Base Image alpine:3
also known as |
|
digest | sha256:6457d53fb065d6f250e1504b9bc42d5b6c65941d57532c072d929dd0628977d0 |
vulnerabilities |
stdlib
|
Affected range | <1.21.11 |
Fixed version | 1.21.11 |
EPSS Score | 0.06% |
EPSS Percentile | 27th percentile |
Description
The various Is methods (IsPrivate, IsLoopback, etc) did not work as expected for IPv4-mapped IPv6 addresses, returning false for addresses which would return true in their traditional IPv4 forms.
Affected range | <1.21.12 |
Fixed version | 1.21.12 |
EPSS Score | 0.04% |
EPSS Percentile | 16th percentile |
Description
The net/http HTTP/1.1 client mishandled the case where a server responds to a request with an "Expect: 100-continue" header with a non-informational (200 or higher) status. This mishandling could leave a client connection in an invalid state, where the next request sent on the connection will fail.
An attacker sending a request to a net/http/httputil.ReverseProxy proxy can exploit this mishandling to cause a denial of service by sending "Expect: 100-continue" requests which elicit a non-informational response from the backend. Each such request leaves the proxy with an invalid connection, and causes one subsequent request using that connection to fail.
Affected range | <1.21.11 |
Fixed version | 1.21.11 |
EPSS Score | 0.04% |
EPSS Percentile | 10th percentile |
Description
The archive/zip package's handling of certain types of invalid zip files differs from the behavior of most zip implementations. This misalignment could be exploited to create an zip file with contents that vary depending on the implementation reading the file. The archive/zip package now rejects files containing these errors.
github.com/hashicorp/go-getter 1.7.4
(golang)
pkg:golang/github.com/hashicorp/go-getter@1.7.4
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.04% |
EPSS Percentile | 9th 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.
busybox 1.36.1-r15
(apk)
pkg:apk/alpine/busybox@1.36.1-r15?os_name=alpine&os_version=3.19
Affected range | <1.36.1-r16 |
Fixed version | 1.36.1-r16 |
EPSS Score | 0.04% |
EPSS Percentile | 13th percentile |
Description
Affected range | <1.36.1-r19 |
Fixed version | 1.36.1-r19 |
EPSS Score | 0.04% |
EPSS Percentile | 13th percentile |
Description
Affected range | <1.36.1-r19 |
Fixed version | 1.36.1-r19 |
EPSS Score | 0.04% |
EPSS Percentile | 13th percentile |
Description
Affected range | <1.36.1-r17 |
Fixed version | 1.36.1-r17 |
EPSS Score | 0.04% |
EPSS Percentile | 13th percentile |
Description
github.com/cometbft/cometbft 0.37.4
(golang)
pkg:golang/github.com/cometbft/cometbft@0.37.4
Externally Controlled Reference to a Resource in Another Sphere
Affected range | >=0.37.0 |
Fixed version | 0.37.7 |
Description
Name: ASA-2024-008: Instability during blocksync when syncing from malicious peer
Component: CometBFT
Criticality: Medium (ACMv1: I:Moderate; L: Possible)
Affected versions: < v0.38.7Summary
An issue was identified for nodes syncing on an existing network during blocksync in which a malicious peer could cause the syncing peer to panic, enter into a catastrophic invalid syncing state or get stuck in blocksync mode, never switching to consensus. It is recommended for all clients to adopt this patch so that blocksync functions as expected and is tolerant of malicious peers presenting invalid data in this situation. Nodes that are vulnerable to this state may experience a Denial of Service condition in which syncing will not work as expected when joining a network as a client.
Recognition
This issue was reported to the Cosmos Bug Bounty Program on HackerOne on 5/01/24 by unknown_feature. 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 CometBFT, please see https://docs.cometbft.com/.
For more information about the Interchain Foundation’s engagement with Amulet, please see https://github.com/interchainio/security.
Affected range | >=0.37.0 |
Fixed version | 0.37.5 |
Description
Amulet Security Advisory for CometBFT: ASA-2023-002
Component: CometBFT
Criticality: Low
Affected versions: All
Affected users: Validators, Chain Builders + MaintainersSummary
A default configuration in CometBFT has been found to be large for common use cases, and may affect block times and consensus participation when fully utilized by chain participants. It is advised that chains consider their specific needs for their use case when setting the
BlockParams.MaxBytes
consensus parameter. Chains are encouraged to evaluate the impact of having proposed blocks with the maximum allowed block size, especially on bandwidth usage and block latency. Additionally, thetimeout_propose
parameter should be computed using the maximum allowed block size as a reference. This issue does not represent an actively exploitable vulnerability that would result in a direct loss of funds, however it may have a slight impact on block latency depending on a network’s topography.When setting a large
BlockParams.MaxBytes
, there are two main implications:
- Increased bandwidth to propagate a block
- Increased latency to propagate a block
When combined, this may result in less round participation, and in some cases additional rounds may be required to meet the consensus threshold, which could lead to timeouts depending on the topography of a network and environmental factors. These factors can include the number of validators on a network, geographic distribution, network connectivity (including latency, bandwidth, and reachability), the functionality of the modules implementing the logic for a transaction in your chain, etc. The cost to propagate a 21MB block, the default value for
BlockParams.MaxBytes
, will be far higher than the cost of propagating a smaller 1MB block. CometBFT recommends tuning this parameter to a smaller limit if full initial-round participation is an important quality for your chain.Considerations
CometBFT is designed to be configurable by chains, and implements many different configuration variables and parameters to allow chain developers, validators, node operators, and chain participants to customize it best to their use case. A high-performing validator may find it necessary to experiment with tuning local configuration, optimizing network and compute resources, and implementing controls to inhibit spam.
Next Steps for Chains and Validators
To increase awareness of the potential impacts of this default parameter, the CometBFT team has updated the documentation (cometbft/cometbft#1405, v0.34.x, v0.37.x, v0.38.x) for builders and maintainers of chain applications. Additionally, it is recommended that:
Chain ecosystems and their maintainers set a
BlockParams.MaxBytes
configuration appropriate for their use case at the application level; in some cases, fine-tuningBlockParams
may require a network upgrade.Chain ecosystems and their maintainers evaluate how gas is used and required on their chain, including gas and fee parameters, no-fee or fee-exempt message policies, and ensure that any custom modules integrate with the gas and fee frameworks. This is especially important for chains that may have implemented custom modules or functionality to allow IBC messages to bypass fees.
Chain ecosystems and their maintainers audit all of their currently-set parameters and configurations to ensure that they are appropriate for their use case.
All validators develop and implement anti-spam measures on their nodes. Amulet encourages validators to form working groups to collaborate on spam prevention and on tooling that can be implemented by node operators across the Interchain.
All validators consider developing and implementing tooling that would allow them to sample incoming transactions to enable them to fine-tune the level of service they would like to provide to be resilient in slowdown scenarios. Amulet also encourages validators to collaborate on tooling that can be implemented by node operators across the Interchain.
The CometBFT team has also revisited all the checks performed by the consensus protocol regarding proposed blocks. This investigation has confirmed that proposed blocks with size exceeding the
BlockParams.MaxBytes
limit established by the application are not accepted by nodes. The team notwithstanding has decided to introduce additional sanity checks for the size of proposed blocks (cometbft/cometbft#1408), allowing for an early identification and rejection of invalid or oversized blocks. These code changes will be included in the next release of each branch of CometBFT.As more chains adopt the Interchain Stack for new and cutting-edge use cases, the CometBFT team recommends that all chains regularly evaluate their parameters and configurations to ensure they meet the needs of their ecosystem as their networks mature.
For more information about CometBFT, see https://docs.cometbft.com.
This issue was reported via the vulnerability disclosure channel at security@interchain.io on Friday, September 23, 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.
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.
google.golang.org/protobuf 1.32.0
(golang)
pkg:golang/google.golang.org/protobuf@1.32.0
Loop with Unreachable Exit Condition ('Infinite Loop')
Affected range | <1.33.0 |
Fixed version | 1.33.0 |
EPSS Score | 0.04% |
EPSS Percentile | 16th 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This PR adds in authz Grants query into the stargate querier whitelist. to allow contracts make authz query on the Grants endpoint