13 results (0.006 seconds)

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

sigstore-python is a Python tool for generating and verifying Sigstore signatures. Versions of sigstore-python newer than 2.0.0 but prior to 3.6.0 perform insufficient validation of the "integration time" present in "v2" and "v3" bundles during the verification flow: the "integration time" is verified *if* a source of signed time (such as an inclusion promise) is present, but is otherwise trusted if no source of signed time is present. This does not affect "v1" bundles, as the "v1" bundle format always requires an inclusion promise. Sigstore uses signed time to support verification of signatures made against short-lived signing keys. The impact and severity of this weakness is *low*, as Sigstore contains multiple other enforcing components that prevent an attacker who modifies the integration timestamp within a bundle from impersonating a valid signature. In particular, an attacker who modifies the integration timestamp can induce a Denial of Service, but in no different manner than already possible with bundle access (e.g. modifying the signature itself such that it fails to verify). • https://github.com/sigstore/sigstore-python/commit/300b502ae99ebfaace124f1f4e422a6a669369cf https://github.com/sigstore/sigstore-python/releases/tag/v3.6.0 https://github.com/sigstore/sigstore-python/security/advisories/GHSA-hhfg-fwrw-87w7 • CWE-20: Improper Input Validation CWE-325: Missing Cryptographic Step •

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

sigstore-java is a sigstore java client for interacting with sigstore infrastructure. sigstore-java has insufficient verification for a situation where a bundle provides a invalid signature for a checkpoint. This bug impacts clients using any variation of KeylessVerifier.verify(). Currently checkpoints are only used to ensure the root hash of an inclusion proof was provided by the log in question. Failing to validate that means a bundle may provide an inclusion proof that doesn't actually correspond to the log in question. This may eventually lead a monitor/witness being unable to detect when a compromised logs are providing different views of themselves to different clients. • https://github.com/sigstore/sigstore-conformance/pull/139 https://github.com/sigstore/sigstore-java/commit/23fb4885e6704a5df4977f7acf253a745349edf9 https://github.com/sigstore/sigstore-java/security/advisories/GHSA-jp26-88mw-89qr • CWE-20: Improper Input Validation •

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

sigstore-java is a sigstore java client for interacting with sigstore infrastructure. sigstore-java has insufficient verification for a situation where a validly-signed but "mismatched" bundle is presented as proof of inclusion into a transparency log. This bug impacts clients using any variation of KeylessVerifier.verify(). The verifier may accept a bundle with an unrelated log entry, cryptographically verifying everything but fails to ensure the log entry applies to the artifact in question, thereby "verifying" a bundle without any proof the signing event was logged. This allows the creation of a bundle without fulcio certificate and private key combined with an unrelated but time-correct log entry to fake logging of a signing event. A malicious actor using a compromised identity may want to do this to prevent discovery via rekor's log monitors. • https://github.com/sigstore/sigstore-conformance/pull/166 https://github.com/sigstore/sigstore-java/pull/856 https://github.com/sigstore/sigstore-java/security/advisories/GHSA-q4xm-6fjc-5f6w • CWE-347: Improper Verification of Cryptographic Signature •

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

Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. gitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log. gitsign uses Rekor's search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match either condition rather than both. When gitsign's credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry's hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification. • https://github.com/sigstore/gitsign/security/advisories/GHSA-8pmp-678w-c8xx • CWE-706: Use of Incorrectly-Resolved Name or Reference •

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') •