9 results (0.004 seconds)

CVSS: 3.1EPSS: 0%CPEs: 1EXPL: 0

sigstore-go, a Go library for Sigstore signing and verification, is susceptible to a denial of service attack in versions prior to 0.6.1 when a verifier is provided a maliciously crafted Sigstore Bundle containing large amounts of verifiable data, in the form of signed transparency log entries, RFC 3161 timestamps, and attestation subjects. The verification of these data structures is computationally expensive. This can be used to consume excessive CPU resources, leading to a denial of service attack. TUF's security model labels this type of vulnerability an "Endless data attack," and can lead to verification failing to complete and disrupting services that rely on sigstore-go for verification. This vulnerability is addressed with sigstore-go 0.6.1, which adds hard limits to the number of verifiable data structures that can be processed in a bundle. • https://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/signature.go#L183-L193 https://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/tlog.go#L74-L178 https://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/tsa.go#L59-L68 https://github.com/sigstore/sigstore-go/commit/01e70e89e58226286d7977b4dba43b6be472b12c https://github.com/sigstore/sigstore-go/security/advisories/GHSA-cq38-jh5f-37mq • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •

CVSS: 4.2EPSS: 0%CPEs: 1EXPL: 0

Cosign provides code signing and transparency for containers and binaries. Prior to version 2.2.4, maliciously-crafted software artifacts can cause denial of service of the machine running Cosign thereby impacting all services on the machine. The root cause is that Cosign creates slices based on the number of signatures, manifests or attestations in untrusted artifacts. As such, the untrusted artifact can control the amount of memory that Cosign allocates. The exact issue is Cosign allocates excessive memory on the lines that creates a slice of the same length as the manifests. • https://github.com/sigstore/cosign/blob/14795db16417579fac0c00c11e166868d7976b61/pkg/cosign/verify.go#L948-L955 https://github.com/sigstore/cosign/blob/286a98a4a99c1b2f32f84b0d560e324100312280/pkg/oci/remote/signatures.go#L56-L70 https://github.com/sigstore/cosign/commit/629f5f8fa672973503edde75f84dcd984637629e https://github.com/sigstore/cosign/releases/tag/v2.2.4 https://github.com/sigstore/cosign/security/advisories/GHSA-95pr-fxf5-86gv https://access.redhat.com/security/cve/CVE-2024-29903 https://bugzilla.redhat.com/ • CWE-770: Allocation of Resources Without Limits or Throttling •

CVSS: 4.2EPSS: 0%CPEs: 1EXPL: 0

Cosign provides code signing and transparency for containers and binaries. Prior to version 2.2.4, a remote image with a malicious attachment can cause denial of service of the host machine running Cosign. This can impact other services on the machine that rely on having memory available such as a Redis database which can result in data loss. It can also impact the availability of other services on the machine that will not be available for the duration of the machine denial. The root cause of this issue is that Cosign reads the attachment from a remote image entirely into memory without checking the size of the attachment first. • https://github.com/google/go-containerregistry/blob/a0658aa1d0cc7a7f1bcc4a3af9155335b6943f40/pkg/v1/remote/layer.go#L36-L40 https://github.com/sigstore/cosign/blob/9bc3ee309bf35d2f6e17f5d23f231a3d8bf580bc/pkg/oci/remote/remote.go#L228-L239 https://github.com/sigstore/cosign/commit/629f5f8fa672973503edde75f84dcd984637629e https://github.com/sigstore/cosign/releases/tag/v2.2.4 https://github.com/sigstore/cosign/security/advisories/GHSA-88jx-383q-w4qc https://access.redhat.com/security/cve/CVE-2024-29902 https://bugzilla.r • CWE-770: Allocation of Resources Without Limits or Throttling •

CVSS: 5.3EPSS: 0%CPEs: 1EXPL: 0

Gitsign is software for keyless Git signing using Sigstore. In versions of gitsign starting with 0.6.0 and prior to 0.8.0, Rekor public keys were fetched via the Rekor API, instead of through the local TUF client. If the upstream Rekor server happened to be compromised, gitsign clients could potentially be tricked into trusting incorrect signatures. There is no known compromise the default public good instance (`rekor.sigstore.dev`) - anyone using this instance is unaffected. This issue was fixed in v0.8.0. • https://docs.sigstore.dev/about/threat-model/#sigstore-threat-model https://github.com/sigstore/gitsign/commit/cd66ccb03c86a3600955f0c15f6bfeb75f697236 https://github.com/sigstore/gitsign/pull/399 https://github.com/sigstore/gitsign/security/advisories/GHSA-xvrc-2wvh-49vc • CWE-347: Improper Verification of Cryptographic Signature •

CVSS: 5.3EPSS: 0%CPEs: 1EXPL: 1

Cosign is a sigstore signing tool for OCI containers. Cosign is susceptible to a denial of service by an attacker controlled registry. An attacker who controls a remote registry can return a high number of attestations and/or signatures to Cosign and cause Cosign to enter a long loop resulting in an endless data attack. The root cause is that Cosign loops through all attestations fetched from the remote registry in pkg/cosign.FetchAttestations. The attacker needs to compromise the registry or make a request to a registry they control. • https://github.com/sigstore/cosign/commit/8ac891ff0e29ddc67965423bee8f826219c6eb0f https://github.com/sigstore/cosign/security/advisories/GHSA-vfp6-jrw2-99g9 • CWE-400: Uncontrolled Resource Consumption CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •