Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/notaryproject/notation-go >= 1.2.0-beta.1, <= 1.3.0-rc.1
Fixed in
1.3.0-rc.2· Vendor fix available
Issue
This issue was identified during Quarkslab's audit of the timestamp feature. Summary During the timestamp signature generation, the revocation status of the certificate(s) used to generate the timestamp signature was not verified. Details During timestamp signature generation, notation-go did not check the revocation status of the certificate chain used by the TSA. This oversight creates a vulnerability that could be exploited through a Man-in-The-Middle attack. An attacker could potentially use a compromised, intermediate, or revoked leaf certificate to generate a malicious countersignature, which would then be accepted and stored by notation. Impact This could lead to denial of service scenarios, particularly in CI/CD environments during signature verification processes because timestamp signature would fail due to the presence of a revoked certificate(s) potentially disrupting operations.
Recommended action: Upgrade to 1.3.0-rc.2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/notaryproject/notation-go >= 1.3.0-rc.1, <= 1.3.0-rc.1
Fixed in
1.3.0-rc.2· Vendor fix available
Issue
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. Details 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…
Recommended action: Upgrade to 1.3.0-rc.2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/notaryproject/notation-go < 1.0.0-rc.6
Fixed in
1.0.0-rc.6· Vendor fix available
Issue
Impact An attacker who controls or compromises a registry can lead a user to verify the wrong artifact. Patches The problem has been fixed in the release v1.0.0-rc.6. Users should upgrade their notation-go library to v1.0.0-rc.6 or above. Workarounds User should use secure and trusted container registries. Credits The notation project would like to thank Adam Korczynski (@AdamKorcz) for responsibly disclosing the issue found during an security audit (facilitated by OSTIF and sponsored by CNCF) and Shiwei Zhang (@shizhMSFT), Pritesh Bandi (@priteshbandi) for root cause analysis.
Recommended action: Upgrade to 1.0.0-rc.6 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/notaryproject/notation-go < 1.0.0-rc.3
Fixed in
1.0.0-rc.3· Vendor fix available
Issue
Impact notation-go users will find their application using excessive memory when verifying signatures and the application will be finally killed, and thus availability is impacted. Patches The problem has been patched in the release v1.0.0-rc.3. Users should upgrade their notation-go packages to v1.0.0-rc.3 or above. Workarounds Users can review their own trust policy file and check if the identity string contains =#. Meanwhile, users should only put trusted certificates in their trust stores referenced by their own trust policy files, and make sure the authenticity validation is set to enforce Credits The notation-go project would like to thank Adam Korczynski (@AdamKorcz) for responsibly disclosing this issue during a security fuzzing audit sponsored by CNCF and Shiwei Zhang (@shizhMSFT) for root cause analysis and detailed vulnerability report. References - Resource exhaustion attacks
Recommended action: Upgrade to 1.0.0-rc.3 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.