一拖再拖忍无可忍，谷歌披露影响开发人员的 GitHub 高危0day漏洞

 聚焦源代码安全，网罗国内外最新资讯！

编译：奇安信代码卫士团队

谷歌 Project Zero 团队 (GPZ) 披露了 GitHub 的一个高危漏洞。90天期限过后，GitHub 曾要求延期但被拒。

该漏洞是罕见的未能在GPZ规定的90天期限内修复的漏洞。按照谷歌的统计，超过95.8%的漏洞均能在期限内修复。

GPZ素以严格遵守其90天期限而出名，不过这次似乎是因为GitHub 修复速度缓慢而造成的。如下是 GPZ 和 GitHub 沟通的时间线：

• 7月21日，GPZ 团队研究员 Felix Wihelm将漏洞告知 GitHub 且披露日期定为10月18日。

• 10月1日，GitHub 发布安全公告宣布弃用易受攻击的命令，但辩称 Wihelm 所发现的漏洞实际上是一个“中危漏洞“。GitHub 为该漏洞分配的编号是 CVE-2020-15228。

• 10月12日，GPZ 联系 GitHub 并主动提出如果 GitHub 需要更多的修复时间，则可宽限14天。

• 10月16日，GitHub 要求宽限14天，最后披露期限更改为11月2日。

• 10月28日，GPZ 警告 GitHub 称最后期限在下周但未收到任何回应。

• 10月30日，由于未从 GitHub 收到官方回应，GPZ 联系到的相关人员表示，“该问题已修复，GPZ 可按计划在2020年11月2日披露。“

• 11月1日，GitHub 给出官方回应并要求再宽限2天，以便通知客户在后续日期修复。

• 11月2日，GPZ 按照谷歌漏洞披露策略，拒绝 GitHub 在获得104天的期限后仍然要求宽限的请求，最终决定公开该漏洞详情。

漏洞详情

该 bug (CVE-2020-15228) 存在于 GitHub 的 Actions 功能（开发者工作流自动化工具）中。

GitHub Actions 支持“工作流命令”作为 Action runner 和已执行操作之间的通信信道。工作流命令在 runner/src/Runner.Worker/ActionCommandManager.cs中实现，并通过解析查找两个命令标记之一的所有已执行操作的 STDOUT 工作。

V2 命令必须在一行代码的开头开始，如 “::workflow-command

parameter1={data},parameter2={data}::{command value}”。V1 命令也可在一行代码的中间开始，语法如下：“##[command parameter1=data;]command-value”。当前的 GitHub Action runner 版本支持少量不同的命令，但从安全角度来看其中最有意思的一个命令是 “set-env”。如该命令的名称所示，”set-env”可用于将任意环境变量定义为工作流步骤的一部分。按照V1的语法写出将是 ##[set-env name=VERSION;]alpha，将 VERSION=alpha 放入工作流中所有后续步骤的环境中。

该功能存在的一个大问题是，它极易遭注入攻击。当 runner 进程解析打印到 STDOUT （查找工作流命令）的每行代码时，每个打印不受信任内容作为其执行部分的操作均易受攻击。在多数情况下，在另外一个工作流执行时，设置任意环境变量的能力都将导致远程代码执行后果。

Wihelm 指出，查看流行的 GitHub 仓库后发现，几乎任何稍微复杂的 GitHub 操作均易受该漏洞影响。

如下以 VSCode 和 CopyCat 和GitHub 为例进行说明：

（1）    VSCode 和 CopyCat：

VSCode 为每个新开设的问题建立了工作流，运行 https://github.com/microsoft/vscode-github-triage-actions/blob/master/copycat/CopyCat.ts将新的 issue复制到其它仓库中。由于 CopyCat 将不受信任的 issue.title 打印到 stdout，因此易受工作流命令注入攻击。

利用该实例非常容易，只要通过如下 title 打开新的 issue 即可：

##[set-env


name=NODE_OPTIONS;]--experimental-modules


--experimental-loader=data:text/javascript,console.log(Buffer.from(JSON.stringify(process.env)).toSt


ring('hex'));//

这样做将把环境变量 NODE_OPTIONS 设置到字符串

“--experimental-modules


--experimental-loader=data:text/javascript,console.log(Buffer.from(JSON.stringify(process.env)).toSt


ring('hex'));//”

中，而 Node 解释器将在后续的执行步骤中解析该字符串。Wihelm 指出，自己的payload 只是转储以十六进制编码形式编码的进程环境，绕过机密的编辑 (redaction)，但更复杂的 payload 也是有可能实现的。

（2）    actions/stale:

即使 GitHub 自身的操作也易受该漏洞影响。actions/stale 使用 core.info 将不受信任的issue title 转储到 STDOUT。https://github.com/actions/stale/blob/ade4f65ff5df7d690fad2b171eeb852f4809dc0b/src/IssueProcessor.ts#L116 将归结为直接写入 process.stdout (https://github.com/actions/toolkit/blob/1cc56db0ff126f4d65aeb83798852e02a2c180c3/packages/core/src/core.ts#L153)。

幸运的是，stale 通常用作单一步骤的工作流，因此 Wihelm 无法在工作流命令注入之后执行一个步骤的情况下利用该 bug。然而，可按照上述 CopyCat issue 的方式利用 actions/stale 并具有多个步骤的工作流（例如：https://github.com/RocketChat/Rocket.Chat/blob/develop/.github/workflows/stale.yml)。

PoC

Wilhelm 已在私有库 (github.com/felixwilhelm/actions) 中发布了易受攻击的操作和触发器。

修复方案

Wilhelm 指出，自己也并不确定解决该漏洞的最佳方式，他认为工作流命令的实现方式本身就是不安全的。摒弃使用 V1 命令语法并通过允许清单（allowlist） 的方式加固 set-env 的安全很可能防御直接的 RCE 向量问题。然而，即使时覆写后续步骤使用的“正常”环境变量很可能足以利用多数复杂的操作。他还指出，自己并未查看其它工作空间命令的安全影响。长久的修复方案是把工作流命令迁移到某种带外渠道（如新的文件描述符）中，以避免解析 STDOUT，但这样做会使很多已有操作崩溃。他指出，仅修复易受攻击的操作应该无法修复这个问题。从所使用的编程语言来看，几乎无法确保STDOUT 上不会出现恶意代码。

目前，GitHub 发布安全公告宣布弃用易受攻击的命令，但辩称 Wihelm 所发现的漏洞实际上是一个“中危漏洞“。GitHub 为该漏洞分配的编号是 CVE-2020-15228。

推荐阅读

谷歌再次修复已遭利用的两枚高危0day (CVE-2020-16009/16010)

7天期限已过，谷歌披露已遭利用的 Windows 内核 0day 详情

朝鲜黑客被指从黑市购买Oracle Solaris 0day，入侵企业网络

原文链接

https://www.zdnet.com/article/google-to-github-times-up-this-unfixed-high-severity-security-bug-affects-developers/

https://bugs.chromium.org/p/project-zero/issues/detail?id=2070&can=2&q=&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&cells=ids

题图：Pixabay License

本文由奇安信代码卫士编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。

奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的

产品线。

    觉得不错，就点个 “在看” 吧~