GitHub Actions Were Vulnerable to Rust Artifact Poisoning
People are way too inclined to believe that just because some program, language, operating system, or whatever is safer than others, it’s Safe with a capital S. No, no, it’s not. Take Rust, for example. Is it safer than C? You bet! Is it perfectly safe? Heck no! Legit Security recently revealed a new class of software supply chain vulnerability in GitHub Actions and Rust.
This vulnerability leverages artifact poisoning to attack the underlying software development pipelines. In artifact poisoning, the attackers replace a legitimate artifact’s content with a malicious payload. Artifacts in this context are continuous integration/continuous delivery (CI/CD) pipeline products. These include persistent workflow data after a job has been completed for later use, such as log files, core dumps, test results, pictures, etc., and communication channels between jobs in the same workflow.
Attacks on GitHub Actions
Once in place, this malicious data could be used to launch attacks using GitHub Actions and Rust. Specifically, the vulnerability lay in “rust-lang/rustc_codegen_gcc” repository. This enabled any user to execute code in a privileged pipeline. A hacker could then extract repository secrets like cloud credentials, modify project settings, or even tamper with the source code using the GitHub API.
According to Legit Security, “Depending on Rust’s specific configuration, a skilled attacker could probably use these permissions to extend the attack outside the vulnerable repository to additional Rusts assets and move laterally inside the organization.”
The GitHub Actions part of the problem lies within its artifacts storage mechanism. Its cross-workflow artifact communication cannot distinguish between legitimate project artifacts and those created by the project’s forks. This allows an attacker to create a fork that can then craft a malicious artifact.
Making the potential attack much nastier, it can be initiated by any GitHub user. To make it, you could simply create a pull request which in turn uploads a malicious artifact. The attacker doesn’t even need code review approval since the vulnerable build action runs with the malicious code before it’s formally accepted into the project.
So, Liav Caspi, Legit Security’s co-founder and CTO, explained, “This is a different class of vulnerability that can lead to attacks and modification of the development pipeline itself, not simply modification of the code. A simple analogy could be made to a car assembly line. This attack on the assembly line itself could include stealing sensitive parts, turning off certain steps, or substituting any valid part for a malicious one. It’s a powerful attack vector that gives cyber criminals a lot of options to inflict damage.”
In short, this was bad news. While this particular supply chain attack variant is new, we have seen attacks like it before. For example, I was reminded of the CodeCov software supply chain attacks. But it’s a far more sophisticated attack vector.
Vulnerability Fixed
Fortunately, this is all theoretical. Rust and GitHub developers have fixed the vulnerability. However, other GitHub Action projects remain potentially vulnerable.
To mitigate against potential other attacks using this method of exploiting this kind of vulnerability, Legit Security suggests
- You specify which run id or commit hash you download artifacts from before using them.
- Filter out artifacts that were created by pull-request.
- Never trust cross-workflow artifact content. Always sanitize the payload before using it. For example, if you expect a pull-request number make sure the value is a number.
- Make sure you control which workflows are allowed to run by enabling “Require approval for all outside collaborators” in Repository → Settings → Actions → General.
If you do all this, you need not worry about this kind of attack. That said, this also again underlines that you must know exactly what’s in every component you’re using to build your program. If you’re not already using Software Bill of Materials (SBOM)s and Supply-Chain Levels for Software Artifacts (SLSA), it’s way past time to start.
