What does the malicious code actually do?
Malicious Rust crate Arrayref runs a build-time payload
11–20 of 529 posts
Re: Malicious Rust crate Arrayref runs a build-time payload
#12> arrayref is a small crate of four macros.
Why do so many languages fall into this horrible practice?
Re: Malicious Rust crate Arrayref runs a build-time payload
#13Unfortunately Cargo doesn’t have security controls in place to prevent these kinds of attacks. For example pnpm has controls to allowlist install scripts for dependencies and will warn about new install scripts (without executing them). There is an open issue for this: https://github.com/rust-lang/cargo/issues/13681
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 share the dislike for arbitrary build scripts 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 as well, for example with cargo-deny.
Re: Malicious Rust crate Arrayref runs a build-time payload
#14Why this still happens? Why after many previous supply-chain attacks maintainers of package repositories still allow anyone uploading packages and pushing updates without security audit?
Who is funding this security audit? Are folks supposed to volunteer their free time? It's a difficult coordination problem. The best folks have come up is to delay adopting new releases by a few days and hope your dependency is popular enough that a security firm audits it for you in that timespan. If you have enough money I suppose you can start employing llms to audit things for yourself.
> Who is funding this security audit? Are folks supposed to volunteer their free time?
Same people who keep the whole rust project going, a lot of those are volunteers aren't they? Not mad to think they could do the same for core packages at least
Re: Malicious Rust crate Arrayref runs a build-time payload
#15All those folks telling me to update my dependencies, this is why I don't do it. It's not laziness, it's undeniable foresight.
Re: Malicious Rust crate Arrayref runs a build-time payload
#16I’m disappointed crates.io doesn’t have a stricter bar for serving a crate that has newly acquired a proc macro or build.rs. That seems like a trivial mitigation.
Re: Malicious Rust crate Arrayref runs a build-time payload
#17> arrayref is a small crate of four macros. Why do so many languages fall into this horrible practice?
Just like c++ thought threads wasn't a std library concern and then later changed they minds, rust will also change tac I predict
Re: Malicious Rust crate Arrayref runs a build-time payload
#18> arrayref is a small crate of four macros. Why do so many languages fall into this horrible practice?
The languages that have a poor standard library support have this issue and other languages encourage you to import tons of libraries to fix the problem.
This is why Javascript and Typescript suffer from this the most and has little to nothing to do with "popularity" and likely 9/10 of these npm packages import an external library.
Golang on the other-hand is just as popular and has a stronger standard library which people build against and it is encouraged to use its standard library rather than rolling your own or importing another package to solve the problem.
Re: Malicious Rust crate Arrayref runs a build-time payload
#19Why 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 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?
Re: Malicious Rust crate Arrayref runs a build-time payload
#20I’m disappointed crates.io doesn’t have a stricter bar for serving a crate that has newly acquired a proc macro or build.rs. That seems like a trivial mitigation.
Mitigation for what?
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.