GitHub 提交验证逻辑缺陷与绕过
1 分•作者: handwritter•大约 1 个月前
我知道 Git 并非设计成 GitHub 这种运作方式，而伪造问题由来已久，多年来一直被提及。 随着 Shai Hulud 和 AI Agent 的出现，这次情况变得更加严重，因为如果你没有启用 Vigilant Mode 并且没有注册 GPG 密钥，提交验证也可能被伪造。
我理解平台和 Git 本身存在局限性，但设计决策和设计缺陷是完全不同的两回事。 由于令人沮丧的漏洞赏金报告被驳回，以及 MSRC 将提交验证品牌化为缓解方法的讽刺意味，我等了很久才在这里发布。
GitHub 显然有机会进行与平台身份验证令牌和用户注册电子邮件关联的验证，但他们选择了不这样做。 更有讽刺意味的是，当我在等待更多关于这个问题的参与时，他们（GitHub）被黑了，这与这次黑客事件看起来是多么的巧合，简直是无价之宝。
以下是正式内容：
---------------------------------------------------
GitHub 自己的文档建立了一套信任假设，如果遵循其逻辑结论，就会揭示一个无法审计、无法以编程方式检测，并且任何拥有免费 GitHub 帐户的用户都可以利用的验证漏洞。
文档中的链条：
1. GitHub 文档指出，提交签名验证让其他人“确信更改来自可信来源”：
https://docs.github.com/en/authentication/managing-commit-signature-verification
2. 验证检查提交是否使用注册到 GitHub 帐户的 GPG/SSH 密钥进行签名：
https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification
3. Git 每次提交都有两个身份字段：作者（编写代码的人）和提交者（应用代码的人）。两者都可以通过环境变量自由设置——GIT_AUTHOR_NAME、GIT_AUTHOR_EMAIL、GIT_COMMITTER_NAME、GIT_COMMITTER_EMAIL：
https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables
4. GitHub 的 UI 突出显示作者。提交者隐藏在次要点击后面。绿色的“已验证”徽章位于作者的姓名和头像旁边。
5. GitHub 的验证仅绑定到提交者的密钥。作者字段未经过验证、未经过校验且未受约束。API 直接公开了这一点——作者、提交者和验证是每次提交的单独对象：
https://docs.github.com/en/rest/git/commits
逻辑缺陷：
徽章在作者姓名旁边显示“已验证”——但它验证了提交者的密钥。这可以是两个完全不同的人。GitHub 自己的 API 证实了这一点：提交可以返回 author=torvalds, committer=<ANYONE>, verification.verified=true。UI 显示 Linus Torvalds 并带有一个绿色的复选标记。签名密钥是我的。
这并不是加密方面的错误。GPG 签名是有效的。缺陷在于“已验证”所传达的内容与其实际检查的内容之间的差异。
GitHub 知道这一点——并将防御措施限制在受害者身上：
GitHub 实际上有一个“部分验证”徽章状态。当作者 ≠ 提交者并且作者启用了警戒模式时，它会触发：
https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits
这意味着 GitHub 意识到作者-提交者不匹配是一个信任问题。但防御是选择加入的，默认情况下是关闭的，并且取决于被冒充用户的帐户设置——而不是攻击者的设置。攻击者通过选择尚未启用警戒模式的受害者来控制防御是否启动。Linus Torvalds 还没有。大多数 GitHub 用户也没有。
查看原文
I know Git is not designed to use in the way GitHub is operating under and the spoofying had been an old issue that had been brought up throughout the years. With Shai Hulud and AI Agent, this time is abit more serious as the commit verification can be spoofed as well if you did not op in Vigilant Mode AND with a registered GPG key.<p>I understand there are limitations to platform and the Git itself, but design decision and design flaw are totally different things. With the very frustrating bug bounty report dismissal and the ironic branding of commit verification as a mitigation method by the MSRC, I had waited long enough to post it here.<p>GitHub clearly have the chance to do verification associating with the platform auth token and the user registered email but they chosen not to. And adding even more irony they (GitHub) got hacked when I was waiting for more engagement in this issue that ties to this hacked look is priceless.<p>Here's the formalized body:<p>---------------------------------------------------<p>GitHub's own documentation establishes a chain of trust assumptions that, followed to their logical conclusion, reveals a verification gap that cannot be audited, cannot be programmatically detected, and is available to any GitHub user with a free account.<p>The documented chain:<p>1. GitHub docs state that commit signature verification lets other people "be confident that the changes come from a trusted source":
https://docs.github.com/en/authentication/managing-commit-signature-verification<p>2. Verification checks whether the commit is signed with a GPG/SSH key registered to a GitHub account:
https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification<p>3. Git has two identity fields per commit: author (who wrote the code) and committer (who applied it). Both are set freely via environment variables — GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL:
https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables<p>4. GitHub's UI displays the author prominently. The committer is hidden behind a secondary click. The green "Verified" badge sits next to the author's name and avatar.<p>5. GitHub's verification binds only to the committer's key. The author field is not verified, not validated, and not constrained. The API exposes this directly — author, committer, and verification are separate objects on every commit:
https://docs.github.com/en/rest/git/commits<p>The logic flaw:<p>The badge says "Verified" next to the author's name — but it verified the committer's key. These can be two completely different people. GitHub's own API confirms this: a commit can return author=torvalds, committer=<ANYONE>, verification.verified=true. The UI shows Linus Torvalds with a green checkmark. The signing key is mine.<p>This is not a bug in the crypto. The GPG signature is valid. The flaw is in what "Verified" communicates versus what it actually checks.<p>GitHub knows about this — and gated the defense behind the victim:<p>GitHub actually has a "Partially verified" badge state. It triggers when author ≠ committer and the author has enabled vigilant mode:
https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits<p>This means GitHub is aware that author-committer mismatch is a trust problem. But the defense is opt-in, off by default, and gated on the impersonated user's account settings — not the attacker's. The attacker controls whether the defense fires by choosing victims who haven't enabled vigilant mode. Linus Torvalds hasn't. Neither have most GitHub users.