Kev Posted November 4, 2020 Report Posted November 4, 2020 Code shack describes issue as 'moderate' security flaw, plans to disable risky commands gradually Google's bug-hunting Project Zero team has posted details of an injection vulnerability in GitHub Actions after refusing a request to postpone disclosure. The issue arises due to the ability to set environment variables that are then parsed for execution by GitHub Actions. According to the Project Zero disclosure: "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." The problem was discovered in July and reported to GitHub, which issued an advisory deprecating the vulnerable commands, set-env and add-path. GitHub also posted a description of the issue which means that the information posted by Project Zero, while more detailed and including examples, is not such a big reveal. The security hole was assigned CVE-2020-15228 and rated as medium severity. It's hard to fix, as Project Zero researcher Felix Wilhelm noted: "The way workflow commands are implemented is fundamentally insecure." GitHub's solution is to gradually remove the risky commands. Quote "Starting today runner version 2.273.5 will begin to warn you if you use the add-path or set-env commands. We are monitoring telemetry for the usage of these commands and plan to fully disable them in the future," GitHub said last month. The trade-off is that removing the commands will break workflows that use them, but leaving them in place means the vulnerability remains, so folks will be eased off the functionality over time. The Project Zero timeline indicates some frustration with GitHub's response. Normally bug reports are published 90 days after a report is sent to the vendor, or whenever a problem is fixed, whichever is sooner, though this can be extended. On 12 October Project Zero said it told GitHub "that a grace period is available" if it needed more time to disable the vulnerable commands. The response from GitHub was to request a standard 14-day extension to 2 November. On 30 October, Google noted: "Due to no response and the deadline closing in, Project Zero reaches out to other informal Github contacts. The response is that the issue is considered fixed and that we are clear to go public on 2020-11-02 as planned." The implication of that statement is that the post might have been further delayed, yet when GitHub then requested an additional 48 hours "to notify customers," Project Zero said there was "no option to further extend the deadline as this is day 104 (90 days + 14 day grace extension)." Mark Penny, a security researcher at nCipher Security, said on Twitter: Quote "I continually fail to understand how this disclosure methodology is good for anyone except Google... In this particular instance, neither the Google researcher nor Github know how to fix this so deprecation of the vulnerable commands is the order of the day. Yet prior to that deprecation being completed, Project Zero still decide to release PoC code and full details." GitHub has not ignored the problem, but rather has taken steps towards eventually disabling the insecure feature and providing users with an alternative, so it is hard to see the benefit in disclosure other than in the general sense of putting pressure on vendors to come up with speedy fixes. November has not started well for GitHub. The second day of the month saw the site broken by an expired SSL certificate. Along with all the Twitter complaints, one user found something to be grateful for: "@github your certificate for the assets is expired today … Thanks for showing us that this can happen to everyone, small and big companies." ® Via theregister.com 1 Quote
