Gandalf_The_Grey

Level 38
Verified
Trusted
Content Creator
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.

Following the discovery of the security flaw on July 21, the Project Zero team naturally reached out to GitHub with information about the vulnerability, giving them the standard 90 days to resolve it - which would expire on October 18. At the start of this month, GitHub decided to deprecate vulnerable commands and sent out an advisory about a "moderate security vulnerability", asking users to update their workflows. On October 16, GitHub accepted Google's 14-day grace period to fully disable the commands, making November 2 the new deadline.

There has officially been radio silence from GitHub since October 28. Through informal channels, the Project Zero team learned that GitHub plans to request an additional 48 hours. However, this additional grace period is not to patch the issue, but to further notify customers and to determine a "hard date" to fix the vulnerability. As this is not in line with Project Zero's standard disclosure process, the flaw has been made public by the security team today with a proof-of-concept code made available as well.
Read the full article here at Neowin:
 

Gandalf_The_Grey

Level 38
Verified
Trusted
Content Creator
More info and GitHub’s advisory:
 

Gandalf_The_Grey

Level 38
Verified
Trusted
Content Creator
GitHub finally fixes 'high' severity security flaw reported by Google Project Zero:
Google's Project Zero team is dedicated to finding security vulnerabilities in the company's own software as well as those developed by other firms. Its methodology involves privately reporting flaws to vendors and giving them 90 days to fix them before public disclosure. Depending upon the severity of the situation, this deadline may be extended or brought closer according to the group's standard guidelines.

At the start of November, Google publicly disclosed a "high" severity security issue in GitHub following the latter's inability to fix it in 104 days - more than the standard time frame. However, GitHub users will now be pleased to know that the security hole has finally been filled.

The security flaw in question was that workflow commands - which act as a communication channel between executed actions and the Action Runner - in GitHub Actions are extremely vulnerable to injection attacks. Google Project Zero's Felix Wilhelm, who originally reported the security flaw, stated that 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 is also tricky because it would break dependent code. Google publicly disclosed the issue on November 2 following GitHub's failure to fix the issue in the allotted 104 days.

Apparently, this has put some pressure on the company as the vulnerability has now been patched. The patch notes indicate that the fix is in line with Wilhelm's proposed short-term solution:
  • Disabled add-path and set-env runner commands (#779)
  • Updated dotnet install scripts (#779)
The problem was fixed by GitHub a few days ago but has now been validated by the Google Project Zero team, and has been marked as such on the issue repository. This brings the list of open issues reported by the security team down to nine. It includes software developed by numerous vendors including Microsoft, Qualcomm, and Apple. The only open issue present in Google's own software is related to a pointer leak on Android, but the status of this "medium" severity flaw has been open since September 2016.
GitHub finally fixes 'high' severity security flaw reported by Google Project Zero - Neowin
 
Top