Any signed GitHub commit can be copied, without the author's secret key, creating a distinct commit with an identical tree, metadata, a valid signature, and a "Verified" badge

Comments

• eleijeep@piefed.social ⁨2⁩ ⁨days⁩ ago

  This is the opposite of a hash collision (where two different inputs have the same hash), it’s instead a case where the same input can produce two distinct hashes. I’m struggling to think of an actual malicious application of this.

  You would need to have a malicious commit (eg. as part of a supply chain attack) which is signed by a maintainer (because their keys were stolen), and then when the project finally reverts the malicious commit, another attacker (without needing the signing keys) can recreate the malicious commit with a new commit-hash, which might trick automated tools into thinking it’s a new commit, but the tree and metadata would be identical to the malicious commit, and it would be signed using the old (stolen) signing key that would since have been revoked.

  Is that their point? Or is there some other attack that this enables? This just means that we can’t blacklist git commits, since an attacker could produce a new commit hash that represents the same tree. But if an attacker already has the signing keys, then they can do this indefinitely even without this signature malleability. The signing keys would get revoked in both cases, and that’s what needs to be checked.

  source