GitHub Actions Design Flaw Leaves Security Hole for Remote Code Execution
We don’t all use GitHub, but there are certainly a lot of us who use it for managing our Git code repositories. Some of us have also started using GitHub Actions for continuous integration/continuous deployment (CI/CD), but it turns out there’s been a security hole hiding in Actions.
According to Google Project Zero researcher Felix Wilhelm, a GitHub Action design flaw can enable hackers to write to your repositories. And, if that wasn’t bad enough, it can also be used to reveal encrypted secrets.
Whoops!
Wilhelm found that the GitHub Actions workflow command feature acts as a communication channel between the Action Runner and the executed action. So far, so good. But Workflow commands work by parsing STDOUT of all executed actions. One of those commands carried by STDOUT is “set-env.”
You can probably guess where this is going. Yes, that’s right, set-env can define arbitrary environment variables as part of the workflow. This is, as pointed out, “highly vulnerable to injection attacks” Thus, as the runner parses every STDOUT line looking for workflow commands, every Github Action that “prints untrusted content as part of its execution is vulnerable.”
Vulnerable to what you ask? Remote code execution of course.
Wilhelm looked into some popular Github repositories. He discovered almost any project with somewhat complex Github actions is vulnerable. Indeed, “Even Githubs own actions are vulnerable to this issue.”
There may be even more trouble hiding in GitHub Action workflow commands. Wilhelm admitted he didn’t look into the security impact of other workspace commands.
So, what can you do? Wilhelm’s not sure. He thinks, “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 [Remote Code Execution] vectors. However, even the ability to overwrite ‘normal’ environment variables used by later steps is probably enough to exploit most complex actions.”
Of course, one way to fix it for once and for all, Wilhelm suggested was to move workflow commands into some out-of-bound channel (e.g a new file descriptor) to avoid parsing STDOUT.” But, there’s one little problem with that: It would “break a lot of existing action code.”
GitHub hasn’t gone that far, but get ready for some of your existing GitHub Action code to break because GitHub’s developers are removing two of the most vulnerable commands from Runner. “The runner will release an update that disables the set-env and add-path workflow commands in the near future.” By the near future, read by the end of November 2020.
In the meantime, GitHub suggests you “should upgrade to @actions/core v1.2.6 or later, and replace any instance of the set-env or add-path commands in their workflows with the new Environment File Syntax.” If you keep using workflows and actions using the old commands or older toolkit versions you’ll first see warnings and eventually, you’ll error out during workflow execution if you keep trying to use the older insecure commands.
So, once more, as is so often the case with security problems, it’s time to get ready to start patching and to clean up your code. A developer’s security work is never done.
Feature image via Pixabay.
