换句话说 ，a047be8分支实际上"影射"了带有短hash a047be8的commit ， 阻止了短hash提及该commit 。
“幽灵分支”
我做了一个实验 ， 看看GitHub能否很好地处理与commit短hash相匹配的已被删除的分支 。
在前面的例子中 ， 在储存库里有一个带有特定短hash的commit ， 然后我们推送了一个名字与短hash相同的分支 。 当然 ， 我们也可以反过来做——如果一个分支已经存在 ， 我们可以推送一个与该分支名称相同的短hash的commit 。 所以我进行了以下操作 。
- 首先 ， 我推送了一个名为 deadbeef 的分支到GitHub储存库 。
- 然后 ， 我从另一个分支创建了一个拉动请求到 deadbeef。
- 接下来 ， 我删除了 deadbeef 分支 ， 这导致拉动请求自动关闭 。
- 最后 ， 我开始使用我的lucky-commit ， 生成了一个带有短hash deadbeef 的新commit 。 然后我把这个commit也推送到GitHub仓库 。[3]
我正准备放弃 ， 去找别的问题时 ， 我发现了一个奇怪的现象 。 我可以在GitHub的UI上重新打开拉动请求 。
文章图片
这有点奇怪 。 因为通常情况下 ， 对于任何开放的拉取请求 ， 拉取请求的head和基分支都需要存在 。 正如我们之前看到的 ， 如果任何一个分支被删除 ， 拉动请求就会立即关闭 。 但在这种情况下 ， GitHub允许我们在删除基分支后重新打开拉动请求 。
为什么呢？GitHub会认为基分支 deadbeef依然存在——因为当GitHub试图查找 deadbeef分支的代码时 ， 并不是什么都没查找到 ， 而是查找到了有短hash deadbeef的commit 。 因此 ， GitHub才允许重新打开拉动请求 。
返回无意义的拉取请求
在这一点上 ， 我们有一个开放的拉取请求 ， 其中的基分支指向一个带有短hash deadbeef的commit ， 而不是一个实际的分支 。
这与之前提到的博文中描述的情况几乎相同 ， 像这样的"无意义"拉取请求可以用来窃取GitHub Action的敏感信息 。 那篇博文中的漏洞路径在2021年被修复了 ， 为"编辑基分支"端点增加了验证功能——有效防止该端点被用于创建无意义的拉取请求 。 然而 ， 当时GitHub并没有在GitHub Actions后端添加分支存在的检查 。 换句话说 ， GitHub Actions仍然容易受到这些无意义的拉动请求的影响 ， 但人们认为已经不能再创建一个无意义的拉取请求 。
当我尝试使用GitHub Actions的这种新方法来创建无意义的拉动请求时 ， 我发现使用 pull_request_targetActions的工作流程仍有可能窃取敏感信息 。
把想法组合起来
我们设定一个可行的攻击场景 。
- 有写入权限的人在正常的开发工作流中无意中创建了一个名为 deadbeef 的分支（或 AAAAAAA， 或 12345， 或任何其他符合特定限制条件的名称 [4] ） 。
- 攻击者从fork创建一个拉取请求到 deadbeef 分支 ， 然后立即关闭该拉取请求（例如 ， 假装它是错误创建的） 。
- 后来 ， 有人删除了 deadbeef 分支（比如 ， 在这个修改被合并到main分支之后） 。
- 在一个特意制作的有短hash deadbeef f的commit中 ， 攻击者将类似这样的恶意GitHub Actions工作流推送到他们的fork中 。
- 攻击者重新打开拉动请求 。 这导致GitHub在拉动请求的基分支" deadbeef "寻找 pull_request_target 工作流 。
特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。