GitHub has finally fixed a high severity security flaw reported to it by Google Project Zero more than three months ago.
The bug affected GitHub’s Actions feature – a developer workflow automation tool – that Google Project Zero researcher Felix Wilhelm said was “highly vulnerable to injection attacks”. GitHub’s Actions support a feature called workflow commands as a communication channel between the Action runner and the executed action.
While Google described it as a ‘high severity’ bug, GitHub argued it was a ‘moderate security vulnerability’.
SEE: Network security policy (TechRepublic Premium)
Google Project Zero usually discloses any flaws it finds 90 day after reporting them, and by November 2, GitHub had exceeded Google’s one-off grace period of 14 days without having fixed the flaw.
A day before the extended disclosure deadline, GitHub told Google it would not be disabling the vulnerable commands by November 2 and then requested an additional 48 hours – not to fix the issue, but to notify customers and determine a ‘hard date’ at some point in the future. Google then published details of the bug 104 days after it reported the issue to GitHub.
GitHub finally got around to addressing the issue last week by disabling the feature’s old runner commands, “set-env” and “add-path“, as per Wilhelm’s suggestion.
The fix was implemented on November 16, or two weeks after Wilhelm publicly disclosed the issue.
As Wilhelm noted in his bug report, the former version of Github’s action runner command “set-env” was interesting from a security perspective because it can be used to define arbitrary environment variables as part of a workflow step.
“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,” wrote Wilhelm.
SEE: Google to GitHub: Time’s up – this unfixed ‘high-severity’ security bug affects developers
“In most cases, the ability to set arbitrary environment variables results in remote code execution as soon as another workflow is executed.”
Now that GitHub has disabled the two vulnerable commands, Wilhelm has also updated his issue report to confirm the issue is fixed.
