GitHub Verified Commits Vulnerable to Signature Rewriting
A newly discovered vulnerability allows attackers to rewrite signed Git commits, altering their hashes while maintaining valid signatures and GitHub's 'Verified' status, potentially deceiving reviewers.
Researchers have uncovered a significant flaw in how GitHub verifies signed Git commits, demonstrating that a commit's hash is not the immutable identifier many in the software development world assume it to be. The vulnerability allows an attacker, even without the original signing key, to create a new commit containing the exact same files, author, and timestamp as an existing signed commit. Crucially, this new commit can be given a valid signature, and GitHub will still mark it as 'Verified,' masking the altered commit and its new hash.
This presents a critical issue for systems that rely on commit hashes for deduplication, provenance tracking, and reproducible builds. If a specific commit hash is blocked or flagged, an attacker could re-push the identical content under a new, validly signed, and 'Verified' hash that bypasses existing security measures. Similarly, a compromised or malicious repository mirror could serve validly signed commits with different hashes than those on the canonical source, undermining trust in the commit history.
The research, conducted by Jacob Ginesin, a PhD student at Carnegie Mellon University, highlights that the problem is not with Git's cryptographic algorithms themselves, but with how forges like GitHub interpret and validate signatures. The core issue stems from signature malleability, where certain valid signatures can be rewritten into different, yet still valid, forms. This alteration changes the commit's hash without modifying the actual code or metadata, which is what the signature is supposed to protect.
Ginesin detailed three primary methods for exploiting this malleability, each targeting different signature schemes used by GitHub. For ECDSA keys, the 's' value in the signature can be mathematically transformed into 'n - s', resulting in a different hash but a still-valid signature. For RSA and EdDSA keys, an extra, ignored field can be added to the signature, altering the commit's bytes and hash while passing verification. Finally, for S/MIME (X.509) keys, a non-standard, longer encoding of a length field can be used, which GitHub accepts despite strict local checks rejecting it.
The common thread across these exploits is GitHub's failure to normalize signatures before verifying them. The platform accepts various forms of signatures without enforcing canonical encoding or stripping extraneous fields. Consequently, GitHub associates a 'Verified' status with a commit hash, and this status persists even if the underlying signature is altered or the signing key is later revoked. This means a commit can appear 'Verified' even after its hash has been changed, creating a deceptive state for reviewers and automated systems.
It is important to note that this is not a hash collision vulnerability; it does not mean two different commits can share the same hash. Instead, it's the reverse: a single set of content can be represented by multiple validly signed commits, each with its own unique hash. This echoes historical issues, such as in Bitcoin's early days, where signature malleability allowed transaction IDs to be altered. The solution then involved accepting only canonical signature forms and moving signatures out of transaction IDs.
The implications extend to supply chain security, particularly in the context of tools like GitHub Actions. While pinning dependencies to specific commit hashes remains a crucial defense against attacks like those seen with tj-actions/changed-files and trivy-action, this research cautions against over-reliance on the 'Verified' status as a sole indicator of integrity. A valid signature confirms the signer, but not the immutability of the commit's hash.
The responsibility for fixing this vulnerability lies with the code forges, such as GitHub. They must implement signature canonicalization before trusting commit hashes. Developers pinning dependencies to specific hashes are still protected, as the pinned hash will always retrieve the correct content. However, systems that rely solely on the 'Verified' status of a commit hash for provenance or integrity checks are exposed and need to be updated to canonicalize signatures before trusting the associated hash.