A pair of security vulnerabilities discovered in the GitHub environments of two very popular open source projects from Apache and Google could be used to stealthily modify project source code, steal secrets, and move laterally inside an organization.
The issues are continuous integration/continuous delivery (CI/CD) flaws that could threaten many more open source projects around the world, according to researchers at Legit Security, who found them affecting a Google Firebase project and a popular integration framework project run by Apache.
Researchers dubbed the vulnerability pattern “GitHub Environment Injection.” It allows attackers to take control of a vulnerable project’s GitHub Actions pipeline by creating a specially crafted payload written to a GitHub environment variable called “GITHUB_ENV.”
Specifically, the issue exists in the way GitHub shares environment variables in the build machine, which can be manipulated to extract information, including the repository ownership credentials.
“The concept is that the build action itself trusts the code that is submitted for review in a way that you don’t need anybody to review it,” explains Liav Caspi, CTO and co-founder of Legit Security. “The mere fact that somebody makes a contribution tricks the build system into executing something about the code. There is a kind of automated test that runs, and you can make the test execute whatever you put there.”
He adds: “The problem there is that anybody that makes a contribution could trigger that without the need for somebody to review it. So, that’s very powerful.”
Don’t Ignore Security for CI/CD Pipelines
According to Caspi, his team found the flaws as a part of an ongoing investigation into CI/CD pipelines. With a surge in SolarWinds-style supply chain flaws, they’d particularly been seeking out weaknesses in the GitHub ecosystem, since it’s one of the most popular source code management (SCM) systems in the open source world and in enterprise development — and thus a natural vehicle for injecting vulnerabilities into software supply chains.
He explains that these flaws manifest both a design weakness in the way that the GitHub platform is designed and how different open source projects and enterprises use the platform.
“You could potentially write a very safe build script if you are super aware of the risks and circumvent a lot of risky operations,” he explains. “But I think nobody is really aware of that, and there are a couple of mechanisms within GitHub Actions that are very dangerous that are used in everyday build operations.”
He says that enterprise development teams should always assume zero trust with GitHub Action and other build systems.
“They should assume that the components they’re using to build — whether it is a build plug-in or anything submitted to them — that an attacker could leverage that,” he says. “And then they should isolate the environment and also review code in a way that it doesn’t execute code submitted for you.”
As Caspi explains, these flaws illustrate not only that the open source project itself a potential vector for supply chain vulnerabilities, but so is the code that makes up the CI/CD pipeline and its integration.
Both bugs have been patched.