GHSA-57WX-M636-G3G8
Vulnerability from github – Published: 2024-01-19 22:12 – Updated: 2024-03-01 15:19Impact
An external actor with control of a compromised container registry can provide outdated versions of OCI artifacts, such as Images. This could lead artifact consumers with relaxed trust policies (such as permissive instead of strict) to potentially use artifacts with signatures that are no longer valid, making them susceptible to any exploits those artifacts may contain.
Mitigation
In Notary Project, an artifact publisher can control the validity period of artifact by specifying signature expiry during the signing process. Using shorter signature validity periods along with processes to periodically resign artifacts, allows artifact producers to ensure that their consumers will only receive up-to-date artifacts. Artifact consumers should correspondingly use a strict or equivalent trust policy that enforces signature expiry. Together these steps enable use of up-to-date artifacts and safeguard against rollback attack in the event of registry compromise. The Notary Project offers various signature validation options such as permissive, audit and skip to support various scenarios. These scenarios includes 1) situations demanding urgent workload deployment, necessitating the bypassing of expired or revoked signatures; 2) auditing of artifacts lacking signatures without interrupting workload; and 3) skipping of verification for specific images that might have undergone validation through alternative mechanisms.
Additionally, the Notary Project supports revocation to ensure the signature freshness. Artifact publishers can sign with short-lived certificates and revoke older certificates when necessary. This revocation serves as a signal to inform artifact consumers that the corresponding unexpired artifact is no longer approved by the publisher. This enables the artifact publisher to control the validity of the signature independently of their ability to manage artifacts in a compromised registry.
Credit
The Notary Project extends its gratitude to Justin Cappos (@JustinCappos) for responsibly disclosing the issue.
_Note: we have updated threat model to include considerations for rollback attack.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/notaryproject/notation"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-23332"
],
"database_specific": {
"cwe_ids": [
"CWE-672"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-19T22:12:22Z",
"nvd_published_at": "2024-01-19T23:15:07Z",
"severity": "MODERATE"
},
"details": "### Impact\nAn external actor with control of a compromised container registry can provide outdated versions of OCI artifacts, such as Images. This could lead artifact consumers with relaxed trust policies (such as `permissive` instead of `strict`) to potentially use artifacts with signatures that are no longer valid, making them susceptible to any exploits those artifacts may contain.\n\n### Mitigation\nIn Notary Project, an artifact publisher can control the validity period of artifact by specifying signature expiry during the signing process. Using shorter signature validity periods along with processes to periodically resign artifacts, allows artifact producers to ensure that their consumers will only receive up-to-date artifacts. Artifact consumers should correspondingly use a `strict` or equivalent trust policy that enforces signature expiry. Together these steps enable use of up-to-date artifacts and safeguard against rollback attack in the event of registry compromise. The Notary Project offers various signature validation options such as `permissive`, `audit` and `skip` to support various scenarios. These scenarios includes 1) situations demanding urgent workload deployment, necessitating the bypassing of expired or revoked signatures; 2) auditing of artifacts lacking signatures without interrupting workload; and 3) skipping of verification for specific images that might have undergone validation through alternative mechanisms.\n\nAdditionally, the Notary Project supports revocation to ensure the signature freshness. Artifact publishers can sign with short-lived certificates and revoke older certificates when necessary. This revocation serves as a signal to inform artifact consumers that the corresponding unexpired artifact is no longer approved by the publisher. This enables the artifact publisher to control the validity of the signature independently of their ability to manage artifacts in a compromised registry.\n\n### Credit\nThe Notary Project extends its gratitude to Justin Cappos (@JustinCappos) for responsibly disclosing the issue.\n\n_**Note:** we have updated [threat model](https://github.com/notaryproject/specifications/blob/main/threatmodels/notation-threatmodel.md) to include considerations for rollback attack.",
"id": "GHSA-57wx-m636-g3g8",
"modified": "2024-03-01T15:19:13Z",
"published": "2024-01-19T22:12:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/notaryproject/specifications/security/advisories/GHSA-57wx-m636-g3g8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23332"
},
{
"type": "WEB",
"url": "https://github.com/notaryproject/specifications/commit/cdabdd1042de2999c685fa5d422a785ded9c983a"
},
{
"type": "PACKAGE",
"url": "https://github.com/notaryproject/specifications"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:N/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Go package github.com/notaryproject/notation configured with permissive trust policies potentially susceptible to rollback attack from compromised registry"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.