Posted by abhisek 8 hours ago
That name looked familiar to me; I believe it's the same David Roundy who was an academic at Reed College who wrote DARCS, which is version control software. I used DARCS when I started grad school around 2010 before switching to git.
The fact is that your dependencies are your responsibility. You should be staying up to date on what you depend on and their vulnerabilities. Most vulnerabilities affect specific code paths which may not be present in your code base and do not require mitigation. These are decisions you can make by understanding what your dependencies are instead of offloading to automated package management systems.
NPM has been the posterchild of these types of issues but the dependency stack I saw everytime I compiled even simple programs in Rust made me think Rust would be impacted next. Personally I think third party modules that are effectively universally used (axum, tokio, serde) should be integrated directly into the language.
Just because you don't develop a package manager for your language, doesn't mean someone else won't. See NPM.
It seems like we should be building and testing everything in bubblewrap or some other sandbox going forward.
Developer machines are quite juicy targets. They tend to have all sorts of credentials lying around, so it often isn't too difficult to escalate from that to compromising AWS/GCP/etc.
On top of that there's very little preventing a compromise. Developers are inherently expected to run untrusted code, and the usual Linux / MacOS laptop probably isn't even running any kind of anti-virus protection. Want to compromise the downstream app? Now you also need to pass Play Protect & friends.
> It seems like we should be building and testing everything in bubblewrap or some other sandbox going forward.
Yes, we really should. It is frankly a miracle that it has taken so long for fetch-time / install-time code execution to start blowing up in our faces. If we are spending so much effort on run-time isolation, why are we completely ignoring all those practices during development?
You might assume we are able to detect all malicious behavior at runtime. But "stuxnet" and more recently, the xz compromise say otherwise. What if a not-so-popular crate deep in the dependency chain subtly introduced a LPE in it's code?
I won't spoil the claim in the video about what the dependency number is correlated with, and I'm not even sure how true it is in general, but it's very interesting.
Compromising the code that is then most likely run in a test instead of compromising a build script is just a very slight inconvenience for the attacker.
I'm not particularly fond of arbitrary build scripts either, but restricting them will not help the supply chain issue in a significant way.
Also there are several ways to control build.rs execution in the Cargo ecosystem, for example with cargo-deny.
I also disagree a build scripts is a mild convenience. A build script always runs for anyone it’s a dependency for with full access and context and often has access to secrets in CI. A compromised runtime has more limited access and requires actual invocation of code paths (if you’re lying as a dependency that’s never executed, no exploit).
Of course Rust should have language-level support for capabilities so that just invoking a function doesn’t grant it access to arbitrary disk access. But that’s a much more difficult change than tweaking the defaults for cargo.