CVE-2024-23332 (published 2024-01-19T23:15Z)

The Notary Project is a set of specifications and tools intended to provide a cross-industry standard for securing software supply chains by using authentic container images and other OCI artifacts. 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. 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.

CVSS v3 base score: 6.8, MEDIUM (CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-672
cwe_name: Operation on a Resource after Expiration or Release
description: The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
extended_description: 
            
         
         

Fix information:
repo_url: https://github.com/notaryproject/specifications
commit_details: repo_url: https://github.com/notaryproject/specifications
author: Pritesh Bandi
author_date: 2023-11-22 19:39:58-08:00
msg: Update threat model to include rollback attack (#285)

* Update threat model to add rollback attack

Signed-off-by: Pritesh Bandi <priteshbandi@gmail.com>
repository: repo_url: https://github.com/notaryproject/specifications
repo_name: notaryproject/specifications
description: Cross tooling and interoperability specifications
owner: notaryproject
file_changes: filename: notation-threatmodel.md
change_type: ModificationType.MODIFY
diff: @@ -87,3 +87,4 @@ The certificates trusted by the verifier are stored in Notation trust store in t
 | Malicious signature faking to be signed by a signing authority | Tampering      | Mitigated | High   | Notation     | Unlike notary.x509 signing scheme, trusted timestamps are not checked against RFC#3161 TSA servers for notary.x509.signingAuthority signing scheme. An attacker can use this and bypass trusted timestamp checks by crafting a signature that uses notary.x509 keys but with signingAuthority as the signing scheme. | To prevent this threat, notary.x509.signingAuthority signing scheme requires trusted roots to be present in a trust store type called signingAuthority as opposed to CA trust store type for notary.x509 signing scheme |
 | Inaccessible OCSP Responder                                    | Denial of Service      | Not Mitigated | High     | OCSP Responder  | OCSP Responder is not able to service incoming requests or perform up to spec, thus users are unable to validate certificate revocation status | It cannot be mitigated, since revocation status should be retrieved from OCSP responder, which requires network access. Notation verification should fail if revocation check is configured as `enforced` and OCSP responder is inaccessible. Users can configure trust policy to log or skip revocation check if OCSP responder is not reliable. |
 | Compromised Notation dependencies                              | Tampering              | Mitigated | High     | Notation       | The dependencies that built into Notation binary was compromised, this may lead to arbitrary code being executed | Notation keeps dependencies up-to-date and adds new dependency after careful consideration and only if it's absolutely required. Always use static build instead of dynamic linking |
+| Rollback Attack                              | Tampering              | Mitigated | High     | Notation       | Attacker can exploit a compromised repository to return outdated vulnerable artifacts | Signer can employ short signature expiration periods (and periodically re-sign artifacts) or revoke outdated vulnerable artifacts |
\ No newline at end of file

programming_language: Markdown