Skip to main content

lemmy - Link to source

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
PoC: github.com/JakeGinesin/git-cha…

New Research: A "Verified" GitHub Commit Is NOT Unique

Git identifies every object by a hash of its contents, and for a commit that hash covers the tree, the metadata, the message, and the raw bytes of any signature.
International Cyber Digest
#security
This entry was edited (2 weeks ago)
in reply to ☆ Yσɠƚԋσʂ ☆

kevincox
lemmy - Link to source
kevincox
• •

I'm a little confused by what this is saying. It seems that you can create a basically identical commit with a different signature and thus a different (hashed) ID.

So basically you can take a Signature S1 and produce a valid Signature S2 over the same data that is not identical.

This doesn't seem like a very useful exploit primitive to me. Not nothing, but doesn't seem like a big deal. I feel like I am misunderstanding something.

in reply to kevincox

☆ Yσɠƚԋσʂ ☆
lemmy - Link to source
☆ Yσɠƚԋσʂ ☆
• •
A green "Verified" badge on GitHub is supposed to mean that a trusted author signed it, and its ID is a one of a kind fingerprint for that exact code. Turns out that the second promise of a unique fingerprint does not hold. It matters because security teams and package systems behind tools like Go, Nix, and GitHub Actions trust that ID as a unique handle for code. An attacker can reissue the same signed code under a fresh ID that's still verified to slip past.
in reply to ☆ Yσɠƚԋσʂ ☆

kevincox
lemmy - Link to source
kevincox
• •

I don't understand. Why does having two commit IDs with the exact same code cause problems.

A green “Verified” badge on GitHub is supposed to mean that a trusted author signed it


The author did sign it. It is the exact same code.

An attacker can reissue the same signed code under a fresh ID that’s still verified to slip past.


To split past what? At best it seems that they would be able to have a different ID for the exact same code, which seems harmless? Slightly confusing at worst.

Nix also doesn't use PGP signatures, it requires a separate hash of the resulting commit (the files with the .git directory stripped by default).

This entry was edited (2 weeks ago)
in reply to kevincox

jatone
lemmy - Link to source
jatone
• •
sounds like the author thinks because their purist definition is violated its a problem vs it actually being a problem. im in the same boat as you. I dont see the issue with the commit hash changing long as the code doesnt change.
This entry was edited (2 weeks ago)
in reply to kevincox

☆ Yσɠƚԋσʂ ☆
lemmy - Link to source
☆ Yσɠƚԋσʂ ☆
• •
Right, it's not a serious exploit which would allow changing code, but it does allow compromising integrity because changing the id mutates history.
in reply to ☆ Yσɠƚԋσʂ ☆

kevincox
lemmy - Link to source
kevincox
• •
It doesn't mutate history. It just creates a new branch of history in their own fork. Just like any new commit would do.
in reply to kevincox

☆ Yσɠƚԋσʂ ☆
lemmy - Link to source
☆ Yσɠƚԋσʂ ☆
• •
but looking back you have no way to tell which branch is the real one
in reply to ☆ Yσɠƚԋσʂ ☆

kevincox
lemmy - Link to source
kevincox
• •
Please explain what you mean and how this could be abused. What does "real" mean in this context? They both have the same code. It would probably help if you can provide a specific attack that could actually cause harm rather than just stating facts that have unclear risk.
in reply to kevincox

☆ Yσɠƚԋσʂ ☆
lemmy - Link to source
☆ Yσɠƚԋσʂ ☆
• •
My understanding is that you'd end up with two divergent histories and you can't tell which one is the original. I don't know how it could be abused off top of my head, but generally speaking people tend to find ways to abuse these kinds of things.
⇧