I got to watch this attack unfold pretty much in real time as my agents worked the issue. Here is my writeup https://acje.github.io/systems/watching_a_supply_chain_attac...
Malicious Rust crate Arrayref runs a build-time payload
131–140 of 529 posts
Re: Malicious Rust crate Arrayref runs a build-time payload
#132Earlier quoted context omitted.
More than that, we need capability-based languages. No capability passed to it, no permission.
First we need capability-based OSes, like we should have had decades ago if worse-is-better hadn't stuck us with Unix. I don't need to care whether or not a program was written in a capability-aware language if the OS fundamentally takes care of that for me.
FreeBSD does this with Capsicum: https://wiki.freebsd.org/Capsicum
Re: Malicious Rust crate Arrayref runs a build-time payload
#133We need effect based languages now. It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles. If anyone from epic is reading this please give us a timeline for open sorucing the Verse compiler. In the mean time I think it's possible to hack Cargo and run all build scripts in a microVM. The blast radius will be limited to malicious code in the…
Why does every build have the ability to run arbitrary code by default in the first place? That seems like something you should opt into only under very specific scenarios and even then it should probably be built around a WASM sandbox or microVM (as the parent suggested).
Because many many builds end up doing something just a little weird that the build system cannot handle by default. Ideally the build system would be fully property/dependency based and so it wouldn't have to run arbitrary code. In the real world everybody has something weird about their build that the build system cannot make work.
This is partially because for nearly every project the build system is something they need and don't care about. When they need something weird they hack just enough to make it work and never ask "how should the build system change so that this was a property instead of running code", and thus build systems are slow to improve. In a number of cases the build system did have a way to do that thing, but the person didn't know about it.
There are also a lot of code generators out there. I have yet to see a large project which didn't have their own code generator for something specific to their project (protobuf is an example from Google that has escaped and become useful elsewhere, but there are many others that are specific to one project. Yacc is from the 1970s, and stands for "yet another compiler compiler" - implying the idea was already common 50 years ago). You cannot have/use these useful tools without running arbitrary code.
Re: Malicious Rust crate Arrayref runs a build-time payload
#134We need effect based languages now. It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles. If anyone from epic is reading this please give us a timeline for open sorucing the Verse compiler. In the mean time I think it's possible to hack Cargo and run all build scripts in a microVM. The blast radius will be limited to malicious code in the…
I have been working on a cross platform way of sandboxing without a VM:
Re: Malicious Rust crate Arrayref runs a build-time payload
#135Rust finally got hit... This was motivating me to swap away from Rust towards because of the huge number of dependencies. It seemed inevitable. Ginger bill was right, https://www.gingerbill.org/article/2025/09/08/package-manage...
Honestly, Ginger Bill is plain wrong. Just because you don't develop a package manager for your language, doesn't mean someone else won't. See NPM.
yep which people have already done in odin
Re: Malicious Rust crate Arrayref runs a build-time payload
#136[dead]
Re: Malicious Rust crate Arrayref runs a build-time payload
#137Cargo desperately needs sandboxing for build.rs scripts. It’s been attempted before, but didn’t go very far¹. ¹ https://rust-lang.github.io/goals/2024h2/sandboxed-build-scr...
Sandboxing just build.rs would only be be a minor inconvenience for the attacker, nothing more. The attacker can always as easily compromise the binary you build and as soon as you run it (e.g. in a test) you are owned. It would be a big pain for many that are in the unfortunate position to really need build scripts, though.
I imagine it would be sandboxed by default with an escape hatch to run build scripts outside of the sandbox with user verification. It makes people stop and think about what’s happening. Not perfect, but it does help. When working on JS ecosystem projects I manually approve build scripts and spend some time researching dependencies with build scripts to see if I can avoid running the build script. Some people will ignore it and run everything, but it’s a huge step in the right direction to make it operator-decided.
Re: Malicious Rust crate Arrayref runs a build-time payload
#138Why do none of these hijacks embed runtime attacks? It seems like worming the build machines is the goal, rather than compromising downstream users. It seems like we should be building and testing everything in bubblewrap or some other sandbox going forward.
> Why do none of these hijacks embed runtime attacks? It seems like worming the build machines is the goal, rather than compromising downstream users. 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…
Why are developers "inherently expected to run untrusted code"? Running untrusted code on developer machines seems like a terrible idea, given that it will compromise everything they build or deploy and (as you mentioned) all their credentials.
Re: Malicious Rust crate Arrayref runs a build-time payload
#139I am surprised this took so long.
Re: Malicious Rust crate Arrayref runs a build-time payload
#140Doing software development outside of strict containerization, at the very least, looks increasingly prone to disaster. Yes, we can argue about the culture of package management (as some of us have with especially npm from day one), but it's done, and your colleagues or AI sidekicks cannot be trusted not to download whatever and try to build and run it. All you can do is limit the effective blast radius.
minimum-release-age
what if I need a dependency my teammate released 5 minutes ago