If you recently used Cargo, make sure your system didn’t get infected. Here is another article with a little more info: https://www.stepsecurity.io/blog/arrayref-rust-crate-supply-chain-attack
You must log in or register to comment.
These build scripts should really be restricted. For any language, not just Rust.
Ya, this type of design (npm, Rust, Go?) seems crazy to me. I’m glad I use Java in my day job, haven’t run into any build script attacks yet.
I guess Rust probably chose it so you can build easily on any system? But why can build scripts download stuff an me inject it?
Almost all non-trivial projects in any language have external dependencies. And those dependencies have to come from somewhere.
I also wonder what you think Maven/Gradle/…etc job is.
Gradle and Maven create static build artifacts, they do not dynamically run 3rd party build scripts. And it is uncommon (though not impossible) to use dynamic version targets.
I’m it saying it’s an impossible attack vector Java, but I haven’t seen it yet and I’ve seen it a couple times with Rust and countless times with Javascript. The Javascript ones now use your credentials to publish even more malicious build scripts, so it spreads like a virus.
It appears I wasn’t hit, though I easily could have been, as I installed some Rust-based Python packages recently.
I keep telling myself I’m going to containerize more projects, but it’s getting ridiculous now… TBH, maybe more Linux distros need to operate on a more strict “containerize everything by default” principle, as this is going to keep happening.
It appears I wasn’t hit, though I easily could have been, as I installed some Rust-based Python packages recently.
I easily could have been
If you’re using good projects that have
Cargo.lockchecked in (should be about everyone nowadays), an do the right thing using--lockedwithcargo install, then not really, It wouldn’t have been easy.Unless both an upstream (auto-)merging a bot PR updating to the malicious version (bad), and you installing that upstream (spectacularly unlucky), happened to coincide within that 86 minutes the malicious crate was up (39 minutes if advisory-db was hit at any step), which is almost impossible, but more importantly, fully traceable and investigable at the ecosystem level. And if we are talking released versions only, then the upstream would have had to cut a release and publish it also within that window.
But yes, this is a historic first, a malicious publishing of a real crate with real dependants.
Edit: I checked all
arrayrefdependants, and no crate published within the compromised window. No crate explicitly depends on >=0.3.10 (forcing the malicious version). And no crate published after the incident (potentially indicating fixing an earlier mistake) except for a couple of no-name blockchain crates that don’t even have source repos.Well that’s the thing that scares me; I installed some Python packages (via uv) that compile Rust code upon installation.
I don’t know what they do, or how pip handles it. I had to go and dig, and figure out how they install packages and what the original projects use.
The would protect against malicious code running on the Dev’s computer (which AFAICT is the case here), but not against the code created using the infected library running on users’ computers. And honestly, seeing the regularity of supply chain attacks in recent times, I think we need to find a better way to work with supply chains going forward. Although I admittedly don’t have any solutions myself, tbh.
An atomic distro + toolbox may be what you’re looking for, unless you have pretty specific baremetal requirements
pretty specific baremetal requirements
I do, for some things, unfortunately.
I think Firejail or good old systemd sandboxing would be massive improvements though; I just need to invest the energy in setting them up.
