Digital signatures are foundational to modern software security. For OCI (Open Container Initiative) artifacts—like Docker images—robust signature verification ensures you’re pulling exactly what you expect. Libraries like notation-go, developed under the Notary Project, manage signing and verifying those artifacts.

But what happens if part of the signature verification process doesn’t check if its certificates were revoked?

That’s exactly what CVE-2024-56138 is about. Discovered by Quarkslab, this vulnerability in notation-go impacts the security of timestamp signatures, opening doors for man-in-the-middle attacks and potentially disrupting automated CI/CD workflows.

Let’s break it down simply, explain why it matters, show how it works, and tell you what you can do.

What is notation-go?

notation-go is a Go library for creating and verifying digital signatures for OCI artifacts. It follows the Notary Project specification and is often used as the engine inside command line tools and automation systems to protect artifact supply chains.

A key feature: support for timestamp signatures. These are used to confirm when a signature was generated, helping users know if their signature was created while a certificate was still valid.

What went wrong? (The vulnerability)

#### When notation-go's timestamp feature creates a signature, it allows the signature to include a timestamped proof signed by a so-called Timestamp Authority (TSA). To trust this, you normally check the entire path of certificates up to the root—including checking if they've been revoked (via CRL or OCSP).

But notation-go skipped that step.
It didn’t check the revocation status of any certificate in the TSA's certificate chain.

So if the TSA’s certificate—OR an intermediate—had been revoked, the malicious signature would still be accepted as valid by notation-go.

Why does this matter?

- Attackers could use a revoked or compromised certificate to issue legit-looking timestamps, countersignatures, or signatures—even if the certificate was proven unsafe and revoked!
- Automated systems (CI/CD) might trust a tampered or replayed artifact, leading to potential compromise.
- Denial of service: If a revoked certificate made its way into a registry, downstream users could see signature verifications fail *en masse*, breaking deployments and builds.

The Vulnerability in Context: Sample Code

Below is simplified Go-style pseudocode resembling what was found during the Quarkslab audit:

import "github.com/notaryproject/notation-go"

func GenerateTimestampedSignature(data []byte, tsaURL string, tsaCert *x509.Certificate) ([]byte, error) {
    // ... prepare timestamp request

    // Send request to TSA, get timestamp signature response
    tsResp, err := requestTimestamp(tsaURL, data)
    if err != nil {
        return nil, err
    }
    // Validate the response WITHOUT checking revocation
    err = validateTimestamp(tsResp, tsaCert)
    if err != nil {
        return nil, err
    }
    // Merge timestamp into signature
    signature := append(data, tsResp...)
    return signature, nil
}

What's missing?
There should be a check to verify if tsaCert is revoked, using OCSP or CRL.

Example Exploit Scenario

Let’s say Alice and Bob use notation to verify images in CI/CD. Bob’s system fetches images from a registry. If an attacker can get hold of a revoked timestamp certificate or a compromised intermediate CA, they can:

This timestamp is accepted as legit by all users of notation-go before v1.3.-rc.2.

3. Alice and Bob’s automation believes the file is valid and signed, even though it’s not trustworthy.

If the registry administrators later discover this, simply revoking the bad certificate isn’t enough. Notation-go would still treat the previous (now-bogus) signatures as valid, leading to silent failure of the trust chain.

Or, if the revoked certificate is detected later and CI/CD configs start to check, all pipelines suddenly fail on signature verification—leading to denial of service.

References

- GitHub Security Advisory (GHSA-53f9-7vrr-xg79)
- Notation Release v1.3.-rc.2 (Fixes the issue)
- Quarkslab audit blog (not publicly linked as of cutoff)
- Notary Project specification

How to Stay Safe

Upgrade ASAP:
If you use notation-go—or any projects that depend on it—make sure you’re running at least version 1.3.-rc.2 (or newer).

go get github.com/notaryproject/notation-go@v1.3.-rc.2

If you’re using tools that bundle notation-go, check their dependencies or wait for their updates.

There are currently NO workarounds—you must update to protect your pipeline and artifact trust.

Final Thoughts

*The trust in digital signatures is only as strong as every step in the signature and verification process. Not checking revocation status of certificates during timestamp generation is a big gap.*
With CVE-2024-56138, any trust in revocation-based certificate security was undermined in notation-go versions before v1.3.-rc.2.

If you’re running automated CI/CD that depends on artifact signatures, prioritize this security update!


Stay safe, keep your supply chain secure, and always verify that your libraries are up-to-date!

Timeline

Published on: 01/13/2025 22:15:14 UTC