Google Reports High Risk Security Flaw in GitHub

Google Project Zero team is well-known for discovering vulnerabilities and bugs in Google’s own software as well as that developed by other companies.

Its methodology involves identifying security flaws in software and privately reporting them to vendors, giving them 90 days to fix them before public disclosure.

Depending upon the complexity of the fix required, it sometimes also offers additional days in the form of a grace period. In specific scenarios, companies may even be given less than the standard 90 days to fix issues before Google publicly announces them.

Over the past couple of years, the team has revealed major vulnerabilities in Windows; Windows 10 S; as well as macOS kernel; and also iOS, among others.

A couple of days ago, the security team disclosed a zero-day exploit present in various versions of Windows, and today it has revealed a security flaw in GitHub.

 

The vulnerability has been classified as a “high” severity issue by Google Project Zero.

We’ll spare you the nitty-gritty technical details; and you’re free to view them in detail here if you want; but the meat of the matter is that workflow commands in GitHub Actions are extremely vulnerable to injection attacks.

For those unaware, workflow commands act as a communication channel; between executed actions and the Action Runner.
Felix Wilhelm, who discovered the security flaw via source code review, says that:

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.

In his original post, Wilhelm went on to say that he’s unsure how to fix the issue as the way workflow commands are implemented is “fundamentally insecure”. A short-term solution would be to deprecate the command syntax, whereas a long-term fix would involve moving workflow commands to some out-of-bound channel, but that would also break other pieces of dependent code.