Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious Rust crate Arrayref runs a build-time payload

safedep.io

Post reply on HN
Print view View original

81–90 of 529 posts

Re: Malicious Rust crate Arrayref runs a build-time payload

#81

Post by krautsauer »

jakubadamw wrote: post #41

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...

https://news.ycombinator.com/item?id=49374811

(Oh and btw, proc macros also run arbitrary code.)

Re: Malicious Rust crate Arrayref runs a build-time payload

#82

Post by vlovich123 »

praseodym wrote: post #21
vlovich123 wrote: post #16

I’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.

As mentioned by others it’s just as easy for an attacker to modify a crate’s runtime code.

So? Runtime code requires actually executing the malicious code path which isn’t an immediate 100% hit rate for everyone that includes it in the dependency chain. For build.rs it’s a 100% compromise of everyone it’s in the dependency chain for. Additionally, at runtime you may not have access to secrets whereas at build time you most certainly do.

Re: Malicious Rust crate Arrayref runs a build-time payload

#83

Post by skydhash »

superxpro12 wrote: post #39
wasmperson wrote: post #27

Earlier quoted context omitted.

There was a recent talk which explored this question (Dependency Cultures, by Richard Feldman): https://www.youtube.com/watch?v=E82ly38YEEQ Summary: it's cultural. Rust likely inherited the practice from Nodejs, who inherited it from Ruby. I think in Rust online spaces in particular there is also this undercurrent of "you're not smart enough to use certain parts of the language, so download libraries that handle that…

i'd like to welcome you to the hell that is c/c++ dependency management. Make? cmake? qmake? conf? autoconf? configure? autotools? submodules??? AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

None of those (other than submodules which is just vendoring) does dependency management. They are more configuration management than anything. C, Python, Perl (and maybe ruby?) relies on flag switches and environment variables to find all the necessary files and modules for compiling/running a script. Cmake and autoconf just configure those.

With NPM and Rust's focus on project's level dependencies, there's no longer emphasis on API stability. Instead we have breakage every months, forcing everyone on the upgrade treadmill. It's easier to audit C library because they focus mostly on security updates instead of redesigning the API for the nth time.

Re: Malicious Rust crate Arrayref runs a build-time payload

#84

Post by weinzierl »

jakubadamw wrote: post #41

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...

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.

Re: Malicious Rust crate Arrayref runs a build-time payload

#85

Post by yoyohello13 »

cosmic_cheese wrote: post #78

I think we should be taking a more “batteries included” approach to language and library design. The entire reason we’re in this mess is because we’ve decided it’s ok or maybe even preferable if stdlibs are rail thin, rendering base languages near-unusable. I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 tot…

This was actually the main thing that put me off of Rust. I get the argument for a small std lib. I just also don’t agree it’s worth it. Go seems to handle having a batteries included standard lib just fine.

Re: Malicious Rust crate Arrayref runs a build-time payload

#86

Post by leecommamichael »

cosmic_cheese wrote: post #78

I think we should be taking a more “batteries included” approach to language and library design. The entire reason we’re in this mess is because we’ve decided it’s ok or maybe even preferable if stdlibs are rail thin, rendering base languages near-unusable. I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 tot…

The Odin programming language does this! It has also decided not to provide a package manager.

Re: Malicious Rust crate Arrayref runs a build-time payload

#87

Post by mabini »

fnoef wrote: post #73

Oh, so it's not only "JavaScript bad and npm bad". Apparently, if your language uses third party dependency registry, you are prone to malicious code, regardless if it's Javascript or not. Use containers for development. And reduce the amount of third party deps you import into your projects. This is only going to get worse.

[flagged]

Re: Malicious Rust crate Arrayref runs a build-time payload

#88

Post by burnt-resistor »

tancop wrote: post #75

We 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…

More than that, we need capability-based languages. No capability passed to it, no permission.
Post reply on HN