Project Zero released details of a serious security breach on GitHub and they report that the error affects action workflow commands from GitHub and is described as high severity. (This bug was discovered in July, but under the standard 90-day disclosure period, the details have only been released now.)
This flaw became one of the few vulnerabilities that was not fixed properly before the standard 90-day timeframe granted by Google Project Zero expired.
According to Felix Wilhelm (who discovered it), the member of the Project Zero team, the flaw affects the actions function of GitHub, a tool to automate the work of developers. This is because Actions workflow commands are "vulnerable to injection attacks":
“Actions Github supports a feature called workflow commands as a communication channel between the Action runner and the executed action. Workflow commands are implemented in / src / Runner.Worker / ActionCommandManager.cs and it works by parsing STDOUT of all actions performed by looking for one of the two command markers.
Mention that the big problem with this feature is that it is very vulnerable to injection attacks. Because the execution process scans every row printed in STDOUT for workflow commands, every GitHub action that contains untrusted content as part of its execution is vulnerable.
In most cases, the ability to set arbitrary environment variables results in remote code execution as soon as another workflow is running. I've spent some time looking at popular GitHub repositories, and almost any project that uses slightly complex GitHub actions is vulnerable to this kind of bug.
Subsequently, gave some examples of how the bug could be exploited and also suggested a solution:
“I'm really not sure what is the best way to fix it. I think the way the workflow commands are implemented is fundamentally insecure. Depreading the v1 command syntax and strengtheninget-env with an allow list would probably work against direct RCE vectors.
“However, even the ability to override the 'normal' environment variables used in later steps is probably enough to exploit the more complex actions. Nor have I analyzed the security impact of the other controls in the workspace.
Moreover, mention that a good long-term solution it would be to move the workflow commands to a separate channel (eg a new file descriptor) to avoid parsing by STDOUT, but this will break a lot of existing action code.
As for GitHub, its developers posted an advisory on October 1 and deprecated the vulnerable commands, but argued that what Wilhelm found was in fact a "moderate security vulnerability." GitHub assigned the bug identifier CVE-2020-15228:
“A moderate security vulnerability has been identified in the GitHub Actions runtime that can allow the injection of paths and environment variables into workflows that log untrusted data to STDOUT. This can lead to the introduction or modification of environment variables without the intention of the workflow author.
“To help us solve this problem and allow you to dynamically set environment variables, we have introduced a new set of files to handle environment and path updates in workflows.
“If you are using self-hosted brokers, make sure they are updated to version 2.273.1 or higher.
According to Wilhelm, on October 12, Project Zero contacted GitHub and proactively offered them a 14-day window if GitHub wanted more time to disable the vulnerable commands. Of course, the offer was accepted and GitHub was hoping to disable the vulnerable commands after October 19. Project Zero then set the new disclosure date for November 2.
Source: https://bugs.chromium.org