Cargo 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...
Malicious Rust crate Arrayref runs a build-time payload
41–50 of 529 posts
Re: Malicious Rust crate Arrayref runs a build-time payload
#42> arrayref is a small crate of four macros. Why do so many languages fall into this horrible practice?
There are two reasons you might want to use a crate, The first being that you want to use a good solid implementation that you know someone has spent more time doing and works better than almost any solution you could integrate. The second is you don't want to spend time implementing that.
Writing macros in rust is a pretty horrible experience but it's not difficult
Re: Malicious Rust crate Arrayref runs a build-time payload
#43Why 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?
Mozilla, Google and a couple of others are publishing their audits through cargo vet. There are also additional audits done by individuals you can use through cargo crev. Overall the number of audited crates is in the thousands and you will find audits for most of the popular crates.
In the end it is your decision to use unaudited or refuse unaudited crates.
Re: Malicious Rust crate Arrayref runs a build-time payload
#44Earlier quoted context omitted.
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…
I don't think it's just that, though I agree they are clearly correlated. The reason I don't think it's a sufficient explanation is that there is a clear history of large, 3rd party libraries being created exactly to supplement poor standard libraries. C++ has Boost, Java has Apache Commons (though Java also has a pretty huge standard library), arguably we could even say C has Posix/Win32/Cocoa. I believe there is so…
The reason is simple: the package manager works well. Helps if the package manager is standardized and there is a "default" registry for open source projects.
I remember the days where I had to manually put the Spring .jar files into my project. No way I am doing that for 100s of dependencies.
Re: Malicious Rust crate Arrayref runs a build-time payload
#45[flagged]
Re: Malicious Rust crate Arrayref runs a build-time payload
#46Unfortunately 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.
The problem is that build scripts run automatically without user consent or intevention.
`cargo add` is sufficient to compromise you, before you have a chance to even vet the code.
Re: Malicious Rust crate Arrayref runs a build-time payload
#47Earlier quoted context omitted.
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…
I don't think it's just that, though I agree they are clearly correlated. The reason I don't think it's a sufficient explanation is that there is a clear history of large, 3rd party libraries being created exactly to supplement poor standard libraries. C++ has Boost, Java has Apache Commons (though Java also has a pretty huge standard library), arguably we could even say C has Posix/Win32/Cocoa. I believe there is so…
The important difference IMO is in the small vs big libraries culture.
Lots of languages have a bad stdlib but don’t fall into the trap of having thousands of micro libraries.
The reason people do it is because it brings clout and money. Just look for articles defending micro libs: the popular ones are by people who make a living on donations, due to maintaining 1000+ packages.
And collaborating in larger libs/stdlib is hard. Plus: Rust, Node, all have a lot of visibility.
You need a good stdlib culture to avoid it (like Go did).
Re: Malicious Rust crate Arrayref runs a build-time payload
#48> arrayref is a small crate of four macros. Why do so many languages fall into this horrible practice?
[deleted]
Re: Malicious Rust crate Arrayref runs a build-time payload
#49Rust seems barely better than Node in this regard. Go or .Net or anything with a robust standard library seems like the way to go for most projects.
Cargo (and PyPI) is undeniably better than NPM, which is just shockingly bad for cultural reasons. Yet it's not safe, and it's subject to the same class of exploit, as we're seeing. Indeed, the solution is to get away from the wild soup of author-managed dependencies and go with something with an audited collection of software that is maintained by separate human beings from the known-vulnerable hackers writing the s…
> the solution is to get away from the wild soup of author-managed dependencies and go with something with an audited collection of software that is maintained by separate human beings from the known-vulnerable hackers writing the software.
I think we might be able to crowdsource audits. At least in the Rust ecosystem I'm confident that this is feasible with the right tooling.