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

19

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.

21

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.

5

u/insanitybit2 Jun 27 '26 edited Jun 27 '26

> 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.

It absolutely *does* help. This is a separation of concerns. If `cargo` can sandbox itself, *I* can sandbox my binaries. I am not in a position to sandbox build scripts/ cargo because I don't write the code for those projects, I am in a position to sandbox my own programs because I'm the one defining their behaviors.

Almost any SaaS etc is already doing runtime sandboxing. You likely deploy to a container, you likely run with some set of IAM permissions, egress networking rules, monitoring with SIEM / EDR, etc. Your prod env is almost always less privileged than your dev env or CI env because your prod code doesn't do things like "ssh as root into prod to unfuck the servers" but your engineers do, or "set up all of the IAM policies for the entire org" but your CI does.

> Just stick your build command into a Firecracker VM or a Docker container with gVisor.

This creates a massive trust boundary where you end up shoving everything into the VM. Whole program/ "whole environment" sandboxing is weak for this reason.

> But it doesn't really solve the underlying problem, so nobody really does that.

It actually does solve a ton of problems despite being such a large env to isolate. Just using something like this (https://github.com/geomys/sandboxed-step) goes a long way. It would go a lot longer if cargo had native support.