Security audit of the Notary Project

Introduction

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. Notation specification and tooling provide signing and verification workflows for OCI artifacts, signature portability across OCI compliant registries, and integration with 3rd party key management solutions through a plugin model.

The Notary Project is part of the CNCF projects.

Scope

The defined objectives for this collaboration were to perform a security review focused on new enhancements applied on the Notary Project version v1.2.0 and v1.3.0, namely

• Timestamping support (involving notation, notation-go, notation-core-go, and tspclient-go)
• Revocation checking with CRL (involving notation-go and notation-core-go)

Findings

During the time frame of the security audit, Quarkslab has discovered several security issues and vulnerabilities, among which:

• 1 security issue considered as medium severity;
• 1 security issue considered as low severity;
• 9 issues considered informative.

Security issues were reported directly using the project GitHub security advisories.

Two CVEs were issued, namely:

• CVE-2024-56138: Time stamp signature generation lacks certificate revocation check
• CVE-2024-51491: Process crash during CRL-based revocation check on OS using separate mount point for temp Directory

All reported issues have been taken into account by the Notary Project developers. Pull requests for each issue are provided in the audit report.

ID	Title	Description
MEDIUM-5	Revocation in certificate chain unchecked while signing	There is currently no check in the certification chain to see if revoked certificates are used when verifying the time-stamp countersignature received from TSA.
LOW-11	Non-portable way of creating temporary files for CRL's cache	Method os/Rename is used to rename and move a temporary file to the user cache folder. As detailed in the Rename method description, OS specific restrictions may apply. On Linux, it is relying on libc, rename function. As per [rename documentation](https://man7.org/linux/man-pages/man2/rename.2.html), renaming cannot be applied when the source and destination are located on two different mountpoints. On modern Linux operating systems (tested with Fedora 38), dedicated temporary data area is often a dedicated partition of type tmpfs, located in /tmp. An EXDEV error, detailed as "Cross device link not permitted" is therefore raised during the execution of file.WriteFile on such operating systems.
INFO-1	Unused risky flag NoNonce	Definition of flag that could lead to potential security issues and which is never used in practice.
INFO-2	Option for user to choose the Nonce	There is an option in the code that states that the user could choose the Nonce to be used in the request. If not properly chosen, this could lead to potential issue as the nonce needs to be unique for each request.
INFO-3	Lack of check after URL parsin	No check after parsing the TSA's URL of content of the host or the scheme. This means that an empty host or schema is accepted and processed by the CLI. While this does not directly lead to an issue, since those fields are checked later on by third-party code, this, however, requires that this outside check stays.
INFO-4	Abort TSP HTTP Request Response Validation if invalid signature	At this stage of the process, the signature should be verified before processing anything further to follow the principle of defense-in-depth and execute as few as possible instructions with potential malicious data.. The signature is actually verified only at a later stage (see @sec.verifcc).
INFO-6	I01 - Stored XSS by adding JavaScript code to a bundle template	In cms.(*ParsedSignedData).verifySignedAttributes method, if the signerInfo. SignedAttributes slice is empty and the content type specifies id-data, returned values are nil, nil. While following RFC 5652 no error is returned, this case should never happen for a TST because, according to RFC 3161, the content type has to be id-ct-TSTInfo. Returning nil here triggers a generic error later during certificate chain verification because the slice is empty.
INFO-7	Abort Counter-signature verification if invalid signature	When enough data are extracted to verify the signature in the TST itself, the verification process continues to extract and parse the remaining content before checking the validity of the signature.
INFO-8	Shallow Verification of TSA trust store certificates	Verifications performed on the certificates from the TSA trust store are shallow and not sufficient to ensure the certificates are either Root CA certificate or self-signed. This is incoherent behavior since during Initialization phase, the user-specified root certificate is verified to be a valid root CA certificate against crypto/x509.IsRootCertificate. Here, it is only verified that the CA attribute is set, and if not, the self-signature is. An intermediate CA certificate could be specified by the trust store, and an error will be triggered later during the certificate chain verification. This weakness is, however, not a vulnerability because stricter verification will occur later.
INFO-9	No proper error handling when OCSP or CRL are not available	If none of the revocation check methods are available, the returned structure only tells that the status of the certificate is not revokable. This will not trigger any error, even if the revocation verification policy is set to strict.
INFO-10	Non-compliant use of HTTP Status Code	When fetching CRL from specified url, using HTTP Get method, any HTTP status code between 200 and 299 are accepted. Even if an HTTP Status code starting with 2 is usually related to a successful operation, anything but 200 should be rejected here and considered as an error, as it would not make sense to receive something else considering the sent HTTP GET request.

Conclusion

Quarkslab identified several issues or bugs in Notation, a command-line tool implementing the Notary Project specifications. However, only one of them may involve an immediate risk. Quarkslab recognizes the considerable security efforts made by Notary developers to safeguard the tool, mainly thanks to the conscientious implementation of the different related RFCs.

Additionally, Quarkslab provided recommendations and strategies for addressing the issues, helping to strengthen the open-source tool and enhance its security moving forward.

Thanks to the effective communication between Quarkslab auditors, the OSTIF, and the Notary Project development team, the issues were well understood, and a remediation plan was promptly implemented by the developers.