CVSS: 4.2EPSS: 0%CPEs: 1EXPL: 0CVE-2024-29903 – Cosign vulnerable to machine-wide denial of service via malicious artifacts
https://notcve.org/view.php?id=CVE-2024-29903
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: 0CVE-2024-29902 – Cosign vulnerable to system-wide denial of service via malicious attachments
https://notcve.org/view.php?id=CVE-2024-29902
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: 1CVE-2023-46737 – Possible endless data attack from attacker-controlled registry in cosign
https://notcve.org/view.php?id=CVE-2023-46737
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') •
CVSS: 5.5EPSS: 0%CPEs: 1EXPL: 1CVE-2022-36056 – Vulnerabilities with blob verification in sigstore cosign
https://notcve.org/view.php?id=CVE-2022-36056
Cosign is a project under the sigstore organization which aims to make signatures invisible infrastructure. In versions prior to 1.12.0 a number of vulnerabilities have been found in cosign verify-blob, where Cosign would successfully verify an artifact when verification should have failed. First a cosign bundle can be crafted to successfully verify a blob even if the embedded rekorBundle does not reference the given signature. Second, when providing identity flags, the email and issuer of a certificate is not checked when verifying a Rekor bundle, and the GitHub Actions identity is never checked. Third, providing an invalid Rekor bundle without the experimental flag results in a successful verification. • https://github.com/sigstore/cosign/commit/80b79ed8b4d28ccbce3d279fd273606b5cddcc25 https://github.com/sigstore/cosign/security/advisories/GHSA-8gw7-4j42-w388 https://access.redhat.com/security/cve/CVE-2022-36056 https://bugzilla.redhat.com/show_bug.cgi?id=2128820 • CWE-347: Improper Verification of Cryptographic Signature •
CVSS: 9.8EPSS: 0%CPEs: 1EXPL: 2CVE-2022-35929 – False positive signature verification in cosign
https://notcve.org/view.php?id=CVE-2022-35929
cosign is a container signing and verification utility. In versions prior to 1.10.1 cosign can report a false positive if any attestation exists. `cosign verify-attestation` used with the `--type` flag will report a false positive verification when there is at least one attestation with a valid signature and there are NO attestations of the type being verified (--type defaults to "custom"). This can happen when signing with a standard keypair and with "keyless" signing with Fulcio. This vulnerability can be reproduced with the `distroless.dev/static@sha256:dd7614b5a12bc4d617b223c588b4e0c833402b8f4991fb5702ea83afad1986e2` image. • https://github.com/sigstore/cosign/commit/c5fda01a8ff33ca981f45a9f13e7fb6bd2080b94 https://github.com/sigstore/cosign/security/advisories/GHSA-vjxv-45g9-9296 • CWE-347: Improper Verification of Cryptographic Signature •