Package Instance

Cosign's verify-blob-attestation reports false positive when payload parsing fails
## Description

`cosign verify-blob-attestation` may erroneously report a "Verified OK" result for attestations with malformed payloads or mismatched predicate types. For old-format bundles and detached signatures, this was due to a logic flaw in the error handling of the predicate type validation. For new-format bundles, the predicate type validation was bypassed completely.

## Impact

When `cosign verify-blob-attestation` is used without `--check-claims` set to `true`, an attestation that has a valid signature but a malformed or unparsable payload would be incorrectly validated. Additionally, systems relying on `--type <predicate type>` to reject attestations with mismatched types would be lead to trust the unexpected attestation type.

## Patches

v3.0.6, v2.6.3

## Workarounds

Always set `--check-claims=true` for attestation verification.

Cosign verification accepts any valid Rekor entry under certain conditions
### Impact

A Cosign bundle can be crafted to successfully verify an artifact even if the embedded Rekor entry does not reference the artifact's digest, signature or public key. When verifying a Rekor entry, Cosign verifies the Rekor entry signature, and also compares the artifact's digest, the user's public key from either a Fulcio certificate or provided by the user, and the artifact signature to the Rekor entry contents. Without these comparisons, Cosign would accept any response from Rekor as valid. A malicious actor that has compromised a user's identity or signing key could construct a valid Cosign bundle by including any arbitrary Rekor entry, thus preventing the user from being able to audit the signing event.

This vulnerability only affects users that provide a trusted root via `--trusted-root` or when fetched automatically from a TUF repository, when no trusted key material is provided via `SIGSTORE_REKOR_PUBLIC_KEY`. When using the default flag values in Cosign v3 to sign and verify (`--use-signing-config=true` and `--new-bundle-format=true` for signing, `--new-bundle-format=true` for verification), users are unaffected. Cosign v2 users are affected using the default flag values.

This issue had previously been fixed in https://github.com/sigstore/cosign/security/advisories/GHSA-8gw7-4j42-w388 but recent refactoring caused a regression. We have added testing to prevent a future regression.

#### Steps to Reproduce

```
echo blob > /tmp/blob
cosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.1 --use-signing-config=false /tmp/blob
cosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.2 --use-signing-config=false /tmp/blob
jq ".rekorBundle |= $(jq .rekorBundle /tmp/bundle.2)" /tmp/bundle.1 > /tmp/bundle.3
cosign verify-blob --bundle /tmp/bundle.3 --certificate-identity-regexp='.*' --certificate-oidc-issuer-regexp='.*' /tmp/blob
```

### Patches

Upgrade to Cosign v2.6.2 or Cosign v3.0.4. This does not affect Cosign v1.

### Workarounds

You can provide trusted key material via a set of flags under certain conditions. The simplest fix is to upgrade to the latest Cosign v2 or v3 release.

Note that the example below works for `cosign verify`, `cosign verify-blob, `cosign verify-blob-attestation`, and `cosign verify-attestation`.

```
SIGSTORE_REKOR_PUBLIC_KEY=<path to Rekor pub key> cosign verify-blob --use-signing-config=false --new-bundle-format=false --bundle=<path to bundle> <artifact>
```

cosign's `cosign verify-attestaton  --type` 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
- 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. Users should upgrade to cosign version 1.10.1 or greater for a patch. Currently the only workaround is to upgrade.

Cosign malicious artifacts can cause machine-wide DoS
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.  

As an example, these lines demonstrate the problem:

https://github.com/sigstore/cosign/blob/286a98a4a99c1b2f32f84b0d560e324100312280/pkg/oci/remote/signatures.go#L56-L70 

This `Get()` method gets the manifest of the image, allocates a slice equal to the length of the layers in the manifest, loops through the layers and adds a new signature to the slice.

The exact issue is Cosign allocates excessive memory on the lines that creates a slice of the same length as the manifests. 

## Remediation

Update to the latest version of Cosign, where the number of attestations, signatures and manifests has been limited to a reasonable value.

## Cosign PoC

In the case of this API (also referenced above):

https://github.com/sigstore/cosign/blob/286a98a4a99c1b2f32f84b0d560e324100312280/pkg/oci/remote/signatures.go#L56-L70

… The first line can contain a length that is safe for the system and will not throw a runtime panic or be blocked by other safety mechanisms. For the sake of argument, let’s say that the length of `m, err := s.Manifest()` is the max allowed (by the machine without throwing OOM panics) manifests minus 1. When Cosign then allocates a new slice on this line: `signatures := make([]oci.Signature, 0, len(m.Layers))`, Cosign will allocate more memory than is available and the machine will be denied of service, causing Cosign and all other services on the machine to be unavailable.

To illustrate the issue here, we run a modified version of `TestSignedImageIndex()` in `pkg/oci/remote`:

https://github.com/sigstore/cosign/blob/14795db16417579fac0c00c11e166868d7976b61/pkg/oci/remote/index_test.go#L31-L57

Here, `wantLayers` is the number of manifests from these lines:

https://github.com/sigstore/cosign/blob/286a98a4a99c1b2f32f84b0d560e324100312280/pkg/oci/remote/signatures.go#L56-L60

To test this, we want to make `wantLayers` high enough to not cause a memory on its own but still trigger the machine-wide OOM when a slice gets create with the same length. On my local machine, it would take hours to create a slice of layers that fulfils that criteria, so instead I modify the Cosign production code to reflect a long list of manifests:

```golang
// Get implements oci.Signatures
func (s *sigs) Get() ([]oci.Signature, error) {
        m, err := s.Manifest()
        if err != nil {
                return nil, err
        }
        // Here we imitate a long list of manifests
        ms := make([]byte, 2600000000) // imitate a long list of manifests
        signatures := make([]oci.Signature, 0, len(ms))
        panic("Done")
        //signatures := make([]oci.Signature, 0, len(m.Layers))
        for _, desc := range m.Layers {
```

With this modified code, if we can cause an OOM without triggering the `panic("Done")`, we have succeeded.

Cosign bundle can be crafted to successfully verify a blob even if the embedded rekorBundle does not reference the given signature
## Summary

A number of vulnerabilities have been found in `cosign verify-blob`, where Cosign would successfully verify an artifact when verification should have failed.

## Vulnerability 1: Bundle mismatch causes invalid verification.

### Summary
A cosign bundle can be crafted to successfully verify a blob even if the embedded rekorBundle does not reference the given signature.

### Details
Cosign supports "bundles" which intend to allow offline verification of the signature and rekor inclusion. By using the --bundle flag in cosign sign-blob, cosign will create a JSON file called a "bundle". These bundles include three fields: base64Signature, cert, and rekorBundle. The desired behavior is that the verification of these bundles would:

- verify the provided blob using the included signature and certificate
- verify the rekorBundle SET
- verify the rekorBundle payload references the given artifact.

It appears that step three is not being performed, allowing "any old rekorBundle" to pass validation, even if the rekorBundle payload does not reference the provided blob or the certificate and signature in the rekorBundle do not match those at the top level.

### Steps to reproduce
Enable keyless signing:

```
export COSIGN_EXPERIMENTAL=1
```
Create two random blobs:
```
dd bs=1 count=50 </dev/urandom >blob1
dd bs=1 count=50 </dev/urandom >blob2
```
Sign each blob:
```
cosign sign-blob blob1 --bundle bundle1
cosign sign-blob blob2 --bundle bundle2
```
Create a falsified bundle including the base64Signature and cert fields from bundle1 and the rekorBundle from bundle2:
```
jq --slurpfile bundle2 bundle2 '.rekorBundle = $bundle2[0].rekorBundle' bundle1 > invalidBundle
```
Now, the falsified bundle can be used to verify blob1:
```
$ cosign verify-blob blob1 --bundle invalidBundle
tlog entry verified offline
Verified OK
```

### Patches

Users should update to the latest version of Cosign, `1.12.0`.

### Workaround

If you extract the signature and certificate from the `bundle`, you may use it for verification as follows and avoid using an invalid bundle:
```
$ cosign verify-blob blob1 --signature $(jq -r '.base64Signature' bundle1) --certificate $(jq -r '.cert' bundle1)
```

Note that this will make a network call to Rekor to fetch the Rekor entry. However, you may then be subject to Vulnerability 4.

##  Vulnerability 2: Certificate Identities are not checked in some cases

### Summary 

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.

### Details

Users who provide an offline Rekor bundle (`--bundle`) when verifying a blob using `cosign verify-blob` and include flags that check identity such as `--certificate-email` and `--certificate-oidc-issuer` are impacted. Additionally, users who provide the GitHub Actions verification flags such as `--certificate-github-workflow-name` when running `cosign verify-blob` without a bundle, key reference, or certificate are impacted. 

When providing these flags, Cosign ignored their values. If a certificate's identity did not match the provided flags, Cosign would still successfully verify the blob.

### Patches

Users should update to the latest version of Cosign, `1.12.0`.

### Workarounds

There are no workarounds, users should update.

##  Vulnerability 3: Invalid Rekor bundle without the experimental flag will result in successful verification

### Summary

Providing an invalid Rekor bundle without the experimental flag results in a successful verification.

### Details

Users who provide an offline Rekor bundle (`--bundle`) that was invalid (invalid signed entry timestamp, expired certificate, or malformed) when verifying a blob with `cosign verify-blob` and do not set the `COSIGN_EXPERIMENTAL=1` flag are impacted.

When an invalid bundle was provided, Cosign would fallback to checking Rekor log inclusion by requesting proof of inclusion from the log. However, without the `COSIGN_EXPERIMENTAL` flag, Cosign would exit early and successfully verify the blob. 

### Patches

Users should update to the latest version of Cosign, `1.12.0`.

### Workarounds

There are no workarounds, users should update.

##  Vulnerability 4: Invalid transparency log entry will result in successful verification

### Summary

An invalid transparency log entry will result in immediate success for verification.

### Details

Users who provide a signature and certificate to `verify-blob` will fetch the associated Rekor entry for verification. If the returned entry was invalid (invalid signed entry timestamp, invalid inclusion proof, malformed entry with missing verification), then `cosign` [exits](https://github.com/sigstore/cosign/blob/42c6e2a6dd9d92d19077c8e6b7d66d155a5ea28c/cmd/cosign/cli/verify/verify_blob.go#L357) early and succeeds unconditionally.

### Patches

Users should update to the latest version of Cosign, `1.12.0`.

### Workarounds

There are no workarounds, users should update.


## For more information
If you have any questions or comments about this advisory:
* Open an issue in [cosign](https://github.com/sigstore/cosign)
* Send us a message on [Slack](https://sigstore.slack.com/).

Cosign malicious attachments can cause system-wide denial of service
### Summary
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.

### Details
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. As such, a large attachment can make Cosign read a large attachment into memory; If the attachments size is larger than the machine has memory available, the machine will be denied of service. The Go runtime will make a `SIGKILL` after a few seconds of system-wide denial.

The root cause is that Cosign reads the contents of the attachments entirely into memory on line 238 below:

https://github.com/sigstore/cosign/blob/9bc3ee309bf35d2f6e17f5d23f231a3d8bf580bc/pkg/oci/remote/remote.go#L228-L239

...and prior to that, neither Cosign nor go-containerregistry checks the size of the attachment and enforces a max cap. In the case of a remote layer of `f *attached`, go-containerregistry will invoke this API:

https://github.com/google/go-containerregistry/blob/a0658aa1d0cc7a7f1bcc4a3af9155335b6943f40/pkg/v1/remote/layer.go#L36-L40
```golang
func (rl *remoteLayer) Compressed() (io.ReadCloser, error) {
	// We don't want to log binary layers -- this can break terminals.
	ctx := redact.NewContext(rl.ctx, "omitting binary blobs from logs")
	return rl.fetcher.fetchBlob(ctx, verify.SizeUnknown, rl.digest)
}
```

Notice that the second argument to `rl.fetcher.fetchBlob` is `verify.SizeUnknown` which results in not using the `io.LimitReader` in `verify.ReadCloser`:
https://github.com/google/go-containerregistry/blob/a0658aa1d0cc7a7f1bcc4a3af9155335b6943f40/internal/verify/verify.go#L82-L100
```golang
func ReadCloser(r io.ReadCloser, size int64, h v1.Hash) (io.ReadCloser, error) {
	w, err := v1.Hasher(h.Algorithm)
	if err != nil {
		return nil, err
	}
	r2 := io.TeeReader(r, w) // pass all writes to the hasher.
	if size != SizeUnknown {
		r2 = io.LimitReader(r2, size) // if we know the size, limit to that size.
	}
	return &and.ReadCloser{
		Reader: &verifyReader{
			inner:    r2,
			hasher:   w,
			expected: h,
			wantSize: size,
		},
		CloseFunc: r.Close,
	}, nil
}
```

### Impact
This issue can allow a supply-chain escalation from a compromised registry to the Cosign user: If an attacher has compromised a registry or the account of an image vendor, they can include a malicious attachment and hurt the image consumer. 

### Remediation
Update to the latest version of Cosign, which limits the number of attachments. An environment variable can override this value.

Cosign vulnerable to possible endless data attack from attacker-controlled registry
### Summary
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. When doing so, the attacker must return a high number of attestations in the response to Cosign. The result will be that the attacker can cause Cosign to go into a long or infinite loop that will prevent other users from verifying their data. In Kyvernos case, an attacker whose privileges are limited to making requests to the cluster can make a request with an image reference to their own registry, trigger the infinite loop and deny other users from completing their admission requests. Alternatively, the attacker can obtain control of the registry used by an organization and return a high number of attestations instead the expected number of attestations.

The vulnerable loop in Cosign starts on line 154 below:
https://github.com/sigstore/cosign/blob/004443228442850fb28f248fd59765afad99b6df/pkg/cosign/fetch.go#L135-L196

The `l` slice is controllable by an attacker who controls the remote registry.

Many cloud-native projects consider the remote registry to be untrusted, including Crossplane, Notary and Kyverno. We consider the same to be the case for Cosign, since users are not in control of whether the registry returns the expected data.

TUF's security model labels this type of vulnerability an ["Endless data attack"](https://theupdateframework.io/security/), but an attacker could use this as a type of rollback attack, in case the user attempts to deploy a patched version of a vulnerable image; The attacker could prevent this upgrade by causing Cosign to get stuck in an infinite loop and never complete.

### Mitigation
The issue can be mitigated rather simply by setting a limit to the limit of attestations that Cosign will loop through. The limit does not need to be high to be within the vast majority of use cases and still prevent the endless data attack.

Improper Certificate Validation in Cosign
### Impact

Cosign can be manipulated to claim that an entry for a signature exists in the Rekor transparency log even if it doesn't. This requires the attacker to have pull and push permissions for the signature in OCI. This can happen with both standard signing with a keypair and "keyless signing" with Fulcio.

#### Signing with a keypair

<details>

To reproduce this vulnerability, create a keypair and sign an image. Don't store the signature in Rekor:

```
$ cosign generate-key-pair       
$ cosign sign --key cosign.key IMAGE
```

If an attacker has access to the signature in OCI, they can manipulate cosign into believing the entry was stored in Rekor even though it wasn't. To accomplish this, the attacker needs to:

1. Pull the signature image
2. Annotate the signature image with any valid Rekor bundle under the `dev.sigstore.cosign/bundle` annotation
3. Push the signature image back to OCI

Verification then prints out the following:

```
$ cosign verify [--key]  [IMAGE]

Verification for [IMAGE] --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key
  - Any certificates were verified against the Fulcio roots.

[…]
```

The claim that `Existence of the claims in the transparency log was verified offline` is inaccurate since an entry for this image doesn't exist in the log.
The claim that `Any certificates were verified against the Fulcio roots.` is technically correct but since there were no certificates that should be explicitly called out.

</details>

#### "Keyless signing" with an OIDC flow

<details>

To reproduce this vulnerability, sign the image with a Fulcio identity. Don't store the signature in Rekor: 
```
$ COSIGN_EXPERIMENTAL=1 cosign sign IMAGE
[...]
IMAGE appears to be a private repository, please confirm uploading to the transparency log at "https://rekor.sigstore.dev" [Y/N]: n

```

Then, create a keypair and sign the image again. Store an entry for the signature in Rekor:

```
$ cosign generate-key-pair       
$ COSIGN_EXPERIMENTAL=1 cosign sign --key cosign.key IMAGE

Enter password for private key: IMAGE appears to be a private repository, please confirm uploading to the transparency log at "https://rekor.sigstore.dev" [Y/N]: y
```

If an attacker has access to the signature in OCI, they can manipulate cosign into believing the entry was stored in Rekor even though it wasn't. To accomplish this, the attacker needs to:

1. Pull the signature image
2. Copy the rekor bundle from the second signature into the first signature under the `dev.sigstore.cosign/bundle` annotation
3. Push the signature image back to OCI

_Note: For this to work, both signatures must occur during the valid lifespan of the certificate (~20 minutes)._

Verification then prints out the following:

```
$ cosign verify [--key]  [IMAGE]

Verification for [IMAGE] --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key
  - Any certificates were verified against the Fulcio roots.

[…]
```

The claim that `Existence of the claims in the transparency log was verified offline` is inaccurate since an entry for this image doesn't exist in the log.

The claim that `Any certificates were verified against the Fulcio roots.` is technically correct but since there were no certificates that should be explicitly called out.

</details>


### Patches
The vulnerability has been patched in v1.5.2 of cosign.

The `signature` in the `signedEntryTimestamp` provided by Rekor is now compared to the `signature` that is being verified. If these don't match, then an error is returned. If a valid bundle is copied to a different signature, verification should fail. 

Cosign output now only informs the user that certificates were verified if a certificate was in fact verified.


### Workarounds
The only workaround is upgrading.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [cosign](https://github.com/sigstore/cosign)
* Send us a message on [Slack](https://sigstore.slack.com/). Invite link [here](https://join.slack.com/t/sigstore/shared_invite/zt-mhs55zh0-XmY3bcfWn4XEyMqUUutbUQ).

### Thank you
Thank you to @mtrmac for finding and reporting this vulnerability.

Thank you to everyone who worked on fixing this:
* @nsmith5
* @znewman01 
* @dlorenc
* @mattmoor 
* @priyawadhwa