CVE-2023-47122 in gitsign
Summary
by MITRE • 11/11/2023
Gitsign is software for keyless Git signing using Sigstore. In versions of gitsign starting with 0.6.0 and prior to 0.8.0, Rekor public keys were fetched via the Rekor API, instead of through the local TUF client. If the upstream Rekor server happened to be compromised, gitsign clients could potentially be tricked into trusting incorrect signatures. There is no known compromise the default public good instance (`rekor.sigstore.dev`) - anyone using this instance is unaffected. This issue was fixed in v0.8.0. No known workarounds are available.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 12/06/2023
The vulnerability identified as CVE-2023-47122 affects Gitsign versions 0.6.0 through 0.7.x, representing a critical flaw in the software's trust model for Git signing operations. Gitsign is designed to enable keyless Git signing through Sigstore infrastructure, providing a mechanism for developers to sign commits without managing traditional cryptographic keys. The issue stems from the software's approach to validating Rekor public keys, which are essential for verifying the integrity of transparency log entries that Git commits are anchored to. This flaw creates a potential attack vector where an adversary could compromise the upstream Rekor server and manipulate the trust validation process, leading to the acceptance of fraudulent signatures that would otherwise be rejected.
The technical implementation of this vulnerability resides in how Gitsign handles public key retrieval for Rekor verification. Prior to version 0.8.0, the software fetched Rekor public keys directly from the Rekor API endpoint rather than utilizing the local Trust Root Update (TUF) client that should have been responsible for maintaining a secure and verified copy of these keys. This approach violates fundamental security principles by creating a dependency on an external, potentially untrusted source for critical validation components. The TUF client is specifically designed to provide secure, authenticated updates of trust roots and should have been employed to maintain the integrity of the verification process. This deviation from established security practices introduces a single point of failure where a compromised Rekor server could serve malicious public keys that would be accepted by the vulnerable Gitsign clients.
The operational impact of this vulnerability extends beyond simple signature validation issues, as it fundamentally undermines the security guarantees that Git signing is intended to provide. When a compromised Rekor server serves incorrect public keys, attackers could potentially forge signatures that appear legitimate to Gitsign clients, creating a false sense of security for Git repositories that rely on these signatures for integrity verification. This weakness affects the entire Sigstore ecosystem integration within Gitsign, potentially allowing attackers to bypass the transparency log verification that is crucial for detecting malicious activity. The vulnerability is particularly concerning because it operates at the trust validation layer, meaning that even if individual commits are signed correctly, the verification process could be subverted, leading to a false positive authentication result. This type of vulnerability directly relates to CWE-284, which addresses improper access control, and aligns with ATT&CK technique T1553.006 for credential access through manipulation of authentication systems.
The remediation for this vulnerability required a fundamental change in how Gitsign handles Rekor public key validation, specifically implementing the proper use of the local TUF client for retrieving and verifying public keys. Version 0.8.0 addressed this issue by ensuring that public keys are fetched through the established secure channel that maintains integrity through the TUF framework, rather than relying on potentially compromised API endpoints. This fix aligns with industry best practices for maintaining trust in cryptographic systems and represents a return to proper security architecture principles where validation components are obtained through secure, authenticated channels. Organizations using Gitsign should immediately upgrade to version 0.8.0 or later to remediate this vulnerability, as no effective workarounds exist for the specific flaw in the Rekor public key retrieval mechanism. The vulnerability serves as a reminder of the critical importance of maintaining secure trust validation processes in distributed cryptographic systems and demonstrates how seemingly minor architectural decisions can have significant security implications. The fact that the default instance at rekor.sigstore.dev remains unaffected provides some comfort, but the broader ecosystem of Gitsign users who may have configured custom Rekor instances remains at risk until proper updates are applied.