CVE-2024-29903: Cosign vulnerable to machine-wide denial of service via malicious artifacts

Published Apr 10, 2024
·
Updated

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. Version 2.2.4 contains a patch for the vulnerability.

Other sources

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/indextest.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.

GitHub

Affected Software

4 affected componentsFixes available
go/github.com/sigstore/cosign/v2<=2.2.3
2.2.4
go/github.com/sigstore/cosign<=2.2.3
redhat/cosign<2.2.4
2.2.4
sigstore Cosign<2.2.4

Event History

Apr 10, 2024
CVE Published
via MITRE·10:30 PM
Data Sourced
via MITRE·10:30 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·11:15 PM
DescriptionSeverityWeakness
Apr 11, 2024
Advisory Published
via GitHub·05:15 PM

Frequently Asked Questions

1

What is the severity of CVE-2024-29903?

CVE-2024-29903 is classified as a denial of service vulnerability that affects the operation of the Cosign application.

2

How do I fix CVE-2024-29903?

To mitigate CVE-2024-29903, upgrade to Cosign version 2.2.4 or later.

3

Which versions of Cosign are affected by CVE-2024-29903?

CVE-2024-29903 affects Cosign versions prior to 2.2.4.

4

What causes the vulnerability CVE-2024-29903?

CVE-2024-29903 is caused by maliciously-crafted software artifacts that can lead to a denial of service on machines running Cosign.

5

Is there a workaround for CVE-2024-29903?

There is no documented workaround for CVE-2024-29903; the recommended action is to upgrade to the patched version.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203