Recent findings have uncovered a significant vulnerability in the way GitHub handles ‘Verified’ commits. A new study by Jacob Ginesin, a PhD candidate at Carnegie Mellon University, reveals that a signed Git commit’s hash is not as unique as many in the software industry once believed. This discovery shows that anyone, without the required signing key, can create a secondary commit with identical files, author details, and date, yet still carry a valid signature, allowing GitHub to mark it as ‘Verified.’
Understanding the Potential Risks
Despite everything appearing consistent to a reviewer, the commit’s hash differs, which is crucial because numerous systems consider a verified commit hash as a unique identifier for its contents. This discrepancy poses a threat since if a bad commit is blocked using its hash, an attacker can easily re-upload the same content with a new, ‘Verified’ hash that bypasses the blocklist. This vulnerability affects systems relying on deduplication, provenance logs, and reproducible-build records, as they all depend on the commit hash.
Moreover, compromised or malicious mirrors can distribute validly signed commits with different hashes from the original source. However, it’s important to note that this flaw does not provide a method to bypass signature checks with different code, as the files remain identical across all copies. There’s no need for developers to alter their repositories, as the issue lies in how a forge determines what constitutes ‘Verified,’ and the solution must be implemented on the forge’s side.
Technical Background and Implications
Ginesin’s research, published on arXiv, includes a public tool demonstrating the attack and two demo repositories showing that altered commits still receive ‘Verified’ status on GitHub. The issue, termed ‘hash chain malleability,’ arises because a commit’s hash is calculated over all its components, including the raw bytes of the signature in its header. Multiple valid signatures can be re-encoded into different forms, altering the hash without modifying the code itself.
Three methods illustrate the vulnerability across all GPG schemes recognized by GitHub, along with S/MIME. The first involves flipping the signature for ECDSA keys using elliptic-curve algebra. The second adds an extra field to the ‘unhashed’ section for RSA and EdDSA keys, which doesn’t affect the signature’s validity but changes the commit’s bytes and hash. Lastly, the third method modifies a length field in S/MIME keys, which is rejected by strict local checks but accepted by GitHub.
Proposed Solutions and Industry Response
To address this, Ginesin suggests forges should canonicalize signatures before trusting the hash. This approach mirrors Bitcoin’s solution to similar issues with ECDSA symmetry. The research highlights the importance of not solely relying on a commit’s hash as its unique identifier. Instead, systems should verify and canonicalize signatures before processing them.
Ginesin reported this vulnerability to key organizations like GNU, Git, and GitHub earlier this year. Despite this, no action has been taken by Git or any forge as of the research’s publication. The suggested changes are well understood and should start with the S/MIME case, where GitHub accepts commits that strict local checks reject. The research emphasizes the need for ongoing vigilance in software verification processes to maintain security and integrity.
