Github: Widespread injection vulnerabilities in Actions

Github Actions supports a feature called workflow commands
(https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions) as a
communication channel between the Action runner and the executed action. Workflow commands are
implemented in runner/src/Runner.Worker/ActionCommandManager.cs
(https://github.com/actions/runner/blob/0921af735a3c8fb6cf22ddc8a868b742816e24cf/src/Runner.Worker/ActionCommandManager.cs) 
and work by parsing STDOUT of all executed actions looking for one of two
command markers.

V2 commands have to start at the beginning of a line and look like this \u"::workflow-command
parameter1={data},parameter2={data}::{command value}\u". V1 commands can also start in the middle of
a line and have the following syntax: \u"##[command parameter1=data;]command-value\u". The current
version of the Github action runner supports a small number of different commands but the most
interesting one from a security perspective is \u"set-env\u". As the name suggests, \u"set-env\u" can be
used to define arbitrary environment variables as part of a workflow step. A simple example (in V1
syntax) would be ##[set-env name=VERSION;]alpha, which puts VERSION=alpha in the environment of all
succeeding steps in a workflow.

The big problem with this feature is that it is highly vulnerable to injection attacks. As the
runner process parses every line printed to STDOUT looking for workflow commands, every Github
action that prints 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 executed.
I've spent some time looking at popular Github repositories and almost any project with somewhat
complex Github actions is vulnerable to this bug class. A couple of examples to show how this bug
can be exploited in practice:


VSCode and CopyCat:

VSCode has a workflow for newly opened issues which runs
https://github.com/microsoft/vscode-github-triage-actions/blob/master/copycat/CopyCat.ts to copy
new issues into other repositories. As CopyCat prints the untrusted issue.title to stdout, it is
vulnerable to a workflow command injection.
Exploiting this instance is as easy as opening a new issue with the title \u"##[set-env
name=NODE_OPTIONS;]--experimental-modules
--experimental-loader=data:text/javascript,console.log(Buffer.from(JSON.stringify(process.env)).toSt
ring('hex'));//\u"

This will set the environment variable NODE_OPTIONS to the string \u"--experimental-modules
--experimental-loader=data:text/javascript,console.log(Buffer.from(JSON.stringify(process.env)).toSt
ring('hex'));//\u" which will get parsed by the Node interpreter during later execution steps. My
payload simply dumps the process environment in hex-encoded form to bypass secret redaction, but of
course more complex payloads are possible.


actions/stale:

Even Githubs own actions are vulnerable to this issue. actions/stale dumps untrusted issue titles
to STDOUT using core.info https://github.com/actions/stale/blob/ade4f65ff5df7d690fad2b171eeb852f4809dc0b/src/IssueProcessor.ts#L116, which boils down to a direct write to process.stdout
(https://github.com/actions/toolkit/blob/1cc56db0ff126f4d65aeb83798852e02a2c180c3/packages/core/src/core.ts#L153). 
Fortunately, stale is often used as part of a single step workflow and I wasn't able
to exploit this bug class without executing a step after the workflow command injection. However,
workflows that use actions/stale and have multiple steps can be exploited in the same way as the
CopyCat issue from above (one example would be
https://github.com/RocketChat/Rocket.Chat/blob/develop/.github/workflows/stale.yml)


Non-forked pull requests:

Actions that operate on issues are the most obvious attack vector, but non-forked pull requests are
also interesting. Actions triggered by forked pull requests don't have access to write tokens but
an external contributor can just create a pull request between two existing branches in the target
repo to trigger a privileged workflow run.
One interesting example for a vulnerable action is https://github.com/cirrus-actions/rebase which
triggers on /rebase comments on a pull request and which is used by a number of popular Github
repos such as https://github.com/ReactiveX/rxjs.

If the action is executed on a pull request that can't be rebased, the full Github API
representation of the PR is printed to STDOUT:
https://github.com/cirrus-actions/rebase/blob/b58fa7bac6d1d885234db03877f1d599c3ff48c7/entrypoint.sh#L48

This also includes the attacker controlled PR body and title and can be exploited by creating a
non-forked and non-rebasable PR with the following body: ##[set-env
name=NODE_OPTIONS;]--experimental-modules
--experimental-loader=data:text/javascript,console.log(Buffer.from(JSON.stringify(process.env)).toSt
ring('hex'));//\"
(This works even though the body is printed as part of a JSON document as V1 workflow commands can
start in the middle of a line.). Code execution is triggered by just commenting \u"/rebase\u" under the
PR.
As rebase relies on actions/checkout, this even works if rebase is the last step in a workflow.
Current versions of action/checkout define a post-execution step to cleanup git credentials and
which will trigger our exploit.

Suggested Fix:

I'm really not sure about the best way to address this issue. I think the way workflow commands are
implemented is fundamentally insecure. Deprecating the v1 command syntax and hardening set-env with
an allowlist would probably work against the direct RCE vectors. However, even the ability to
overwrite \u"normal\u" environment variables used by later steps is probably enough to exploit most
complex actions. I also did not look into the security impact of other workspace commands.
A good long-term fix would be to move workflow commands into some out-of-bound channel (e.g a new
file descriptor) to avoid parsing STDOUT, but this will break a lot of existing action code. (I do
not think that this should be addressed by simply patching vulnerable actions. Depending on the
programming language used it is pretty much impossible to guarantee that no malicious data will end
up on STDOUT. )


Proof-of-Concept:

My private repo github.com/felixwilhelm/actions includes vulnerable actions and triggers. Please
let me know if I should give someone on your side access to it.


Credits:
Felix Wilhelm of Google Project Zero

This bug is subject to a 90 day disclosure deadline. After 90 days elapse, the bug report will
become visible to the public. The scheduled disclosure date is 2020-10-19. Disclosure at an earlier
date is also possible if agreed upon by all parties.

Related CVE Numbers: CVE-2020-15228,CVE-2020-15228.



Found by: Felix Wilhelm