- cross-posted to:
- kazkassukompais@group.lt
- lobsters@lemmy.bestiver.se
- cross-posted to:
- kazkassukompais@group.lt
- lobsters@lemmy.bestiver.se
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
These build scripts should really be restricted. For any language, not just Rust.
That would be good but it’s not a magic solution to this problem. They would just move the exploit to runtime. Yeay you don’t get hacked if you compile and never run your program.
You can counter that there are some situations where the program is run sandboxed, e.g. if you’re compiling to WASI or microcontroller firmware or whatever. But those are a tiny minority of cases.
Good point. But hey, at least CI would be safer if nothing else and we’d raise the bar.
There have been discussions in the past around sandboxing build scripts, but until that day comes (if it does), I think there could at least be a prompt to approve build scripts for individual package versions. Several JS package managers do this now, and it helps.
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?
It’s necessary to integrate Rust with other languages (to build source code in other languages, generate some bindings, etc). Otherwise you will have to make Cargo understand every other build system in existence, and stay compatible with them forever.
Ideally this should be heavily audited and allowed only when it’s really necessary.
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
itnot 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.In Java world package managers and package registries work with prebuilt libraries because for JVM bytecode it’s sufficient. And if they have native dependencies then they include compiled .dll or .so files that are built on developer’s machine. This makes things simpler but has its own drawbacks (these dependencies work only on architectures and OSes developer thought of, there is no guarantee that the library will be compatible with user’s environment, etc).
In Rust world everything is built from source, including native dependencies. Thsi makes build process much more complicated and necessitates running code on user’s (developer consumes the library as dependency, not end user) machine to build everything that’s not Rust.
I just wanted to ask, how do they build C libraries in JAVA world? And if the answer is they don’t, they just ship binaries, then that’s infinitely worse. And you just confirmed that’s the case 😲😄.
In reality it very rarely happens that native binaries are needed for Java. I’m not even sure what libraries might use them nowadays - I would guess mostly commercial closed source.
I don’t think it’s “infinitely worse”, but it does mean you require builds for whatever platform you are on or you need to manually build it from source as a separate project.
JVM, ELF, Mach-O,… binaries are infinitely worse when the attack vector is “compromised dev machine”.
I’m not sure how anyone would even try to argue against that.
Yep, it’s all binaries.