CVE-2024-51491 in notation-go
Summary
by MITRE • 01/14/2025
notion-go is a collection of libraries for supporting sign and verify OCI artifacts. Based on Notary Project specifications. The issue was identified during Quarkslab's security audit on the Certificate Revocation List (CRL) based revocation check feature. After retrieving the CRL, notation-go attempts to update the CRL cache using the os.Rename method. However, this operation may fail due to operating system-specific limitations, particularly when the source and destination paths are on different mount points. This failure could lead to an unexpected program termination. In method `crl.(*FileCache).Set`, a temporary file is created in the OS dedicated area (like /tmp for, usually, Linux/Unix). The file is written and then it is tried to move it to the dedicated `notation` cache directory thanks `os.Rename`. As specified in Go documentation, OS specific restriction may apply. When used with Linux OS, it is relying on rename syscall from the libc and as per the documentation, moving a file to a different mountpoint raises an EXDEV error, interpreted as Cross device link not permitted error. Some Linux distribution, like RedHat use a dedicated filesystem (tmpfs), mounted on a specific mountpoint (usually /tmp) for temporary files. When using such OS, revocation check based on CRL will repeatedly crash notation. As a result the signature verification process is aborted as process crashes. This issue has been addressed in version 1.3.0-rc.2 and all users are advised to upgrade. There are no known workarounds for this vulnerability.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 02/13/2025
The vulnerability described in CVE-2024-51491 affects the notation-go library, which implements OCI artifact signing and verification capabilities based on Notary Project specifications. This library serves as a critical component in container security workflows where digital signatures ensure the integrity and authenticity of container images and other artifacts. The issue specifically targets the Certificate Revocation List (CRL) based revocation checking mechanism that is essential for maintaining trust in the signing ecosystem. When a CRL is retrieved during signature verification, the system attempts to update the local cache using a file renaming operation that fails under specific operating system conditions, leading to program termination.
The technical flaw resides in the implementation of the `crl.(*FileCache).Set` method where temporary files are created in the operating system's designated temporary directory such as /tmp on Linux systems, and then moved to the application's dedicated cache directory using the `os.Rename` function. This approach violates fundamental operating system constraints, particularly on Linux distributions where the rename system call requires both source and destination files to reside on the same filesystem mount point. When the temporary file is located on a separate mount point like tmpfs and the target cache directory exists on a different mount, the system raises an EXDEV error indicating cross-device link permission failure. This behavior is documented in the Linux manual pages for the rename system call and represents a common limitation when dealing with filesystem operations across different mount points.
The operational impact of this vulnerability is severe and directly affects the reliability of signature verification processes in container security workflows. When the CRL-based revocation check is performed, the system crashes repeatedly due to the failed file renaming operation, causing the entire signature verification process to abort. This failure means that security-conscious organizations using notation-go for container image validation cannot rely on CRL-based revocation checking, potentially allowing revoked certificates to be accepted without proper detection. The crash behavior manifests as unexpected program termination rather than graceful error handling, which can lead to service disruptions and security gaps in automated CI/CD pipelines where signature verification is a mandatory step. This vulnerability particularly affects Linux environments where tmpfs is commonly used for temporary storage, making it prevalent in containerized environments and cloud deployments.
The vulnerability aligns with CWE-390 which addresses "Detection of Error Condition Without Handling" and demonstrates poor error handling in filesystem operations. From an ATT&CK perspective, this issue could be leveraged by adversaries to disrupt security controls during container image validation processes, potentially leading to supply chain attacks where malicious images bypass verification due to system crashes. The mitigation strategy requires upgrading to version 1.3.0-rc.2 or later, as this release addresses the underlying file system operation issue by implementing proper cross-platform file handling mechanisms. The lack of known workarounds means that organizations must immediately implement the upgrade to maintain secure signature verification capabilities. The fix likely involves using a more robust file copy and atomic replacement mechanism that works across different filesystem mount points rather than relying on `os.Rename` for cross-device operations, ensuring that the CRL cache updates function reliably across all supported operating systems and deployment environments.