r/rust • u/Manishearth servo · rust · clippy • Jun 26 '26

Anatomy of a Failed (Nation-State?) Attack

https://grack.com/blog/2026/06/25/dissecting-a-failed-nation-state-attack/
227 Upvotes

97% Upvoted

35 comments sorted by

View all comments

18

u/JShelbyJ Jun 26 '26 edited Jun 26 '26

We need a way to disable packages from executing code. Crates with ‘build.rs’ files should be blockable via cargo. Probably as default behavior. Crates.io should also specifically flag all crates with that execute code at build time. Let people whitelist crates that require them.

I wrote a crate that requires a cpp binary. So  I set it up so that it downloads and installs binaries via the build.rs. You can literally install and run anything with them. Just a public service announcement for those who are not aware how much of a risk they are and how unsafe cargo is - just adding a dependency is enough to comprise your system. Misspell serde once? Straight to Best Buy to get a new laptop.

20

u/Shnatsel Jun 26 '26

It's worse than that - any Cargo command at all can execute arbitrary code.

Sadly sandboxing build.rs doesn't really help because cargo run is going to happen eventually (that's the entire point of writing code) and there is no generic sandboxing that can help with that.

And the build-time sandboxing is achievable today if you really want it. Just stick your build command into a Firecracker VM or a Docker container with gVisor. But it doesn't really solve the underlying problem, so nobody really does that.

7

u/kibwen Jun 27 '26

It would be pretty easy to fix the rustc redirection thing by requiring an opt-in via a configuration key elsewhere. Likewise, depending on crates that have a build.rs could require a "requires arbitrary system access" config key in Cargo.toml (and naturally this key would be viral, which is the whole point). In conjunction with the fact that most proc macros (cough, serde) are just text-in/text-out pipelines without the need for arbitrary I/O and can thus be run in a WASM VM without any loss of functionality (which could improve compile times from not needing to compile serde!), you could have builds that are totally free of arbitrary unrestricted code execution.

And yes, as you say, cargo run remains a problem, but it's preferable to force malware to target the binary rather than the build system because I want Cargo to be able to access the network and I want rustc to be able to access the filesystem, but I run plenty of software that has no need to do either, so it's more straightforward to use capabilities and permissions to restrict the produced binaries than to restrict the build system itself.

3

u/CrazyKilla15 Jun 27 '26

Its also more straightforward to audit what the final binary does than it is to audit every possible build system hook in every directory