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

111–120 of 529 posts

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

#111

Post by insanitybit »

quotemstr wrote: post #109
insanitybit wrote: post #97

Earlier quoted context omitted.

The technical mechanism is exactly the issue to figure out, there's a reason why projects don't have this and it's because different implementations have different tradeoffs.

No, the reason people haven't been doing this -- and we've had technologies for ages -- is that it's a huge pain in the ass, a "tax", that it's hard to get developers inside a company to pay, much less participants in open source ecosystems. Look at how snap, flatpak, etc. provoke people to just turn off security rather than deal with breakages. A new language won't help because the problem is social, not technical.…

You can't simultaneously say that we've had the tech for years and also say that it doesn't work. We have not had the tech for years. x-plat sandboxing is extremely difficult, especially in a way that's performant.

Sandboxing almost always involves having a dedicated, privileged service, due to how operating systems have designed things. It requires platform specific code.

This is a technical problem and a social problem, there's zero reason to believe it's just one.

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

#112

Post by kibwen »

burnt-resistor wrote: post #88
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.

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.

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

#113

Post by quotemstr »

krautsauer wrote: post #81
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.)

There's no good reason a proc macro can't run in a no-IO sandbox by default. None. Doesn't require a language change. Doesn't require some microvmcapabilityeffect BS. It requires looking people straight in the eye and saying "no" when they complain about needing to prompt for privileges.

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

#114

Post by cube00 »

GitHub really needs something finer-grain then just pretending the repo never existed during these incidents. [1]

The bad package version has also just disappeared from crates.io [2] with no indication its been yanked. There's no security advisory there either [3] "No advisories found for this crate."

I feel crates.io was unprepared for a security incident like this since they're managing the response [4]

[1]: https://web.archive.org/web/20260820145918/https://github.co...

[2]: https://crates.io/crates/arrayref/versions

[3]: https://crates.io/crates/arrayref/security (I'd give an Wayback link but that's also broken https://web.archive.org/web/20260820150747/https://crates.io...)

[4]: https://github.com/rustsec/advisory-db/issues/3161#issuecomm...

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

#115

Post by vaylian »

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…

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

It's not the only way. You can sandbox processes. I think sandboxing is the much more reasonable approach, because in the end of the day, there are still closed-source software products where you can't demand that the manufacturers use certain language safety features.

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

#116

Post by throwaway894345 »

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…

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

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

#118

Post by kmeisthax »

pixl97 wrote: post #92
vatsachak wrote: post #15

All those folks telling me to update my dependencies, this is why I don't do it. It's not laziness, it's undeniable foresight.

I mean, yes, update your dependencies. But probably after a week or so after they've been release and tested by the first penguins willing to jump into the ocean.

Holding periods for new updates are a good idea, but I would also prefer having a tool that could provide diffs of the entire project state pre- and post-update; including transitive dependencies being added or removed. Git diffs won't show you that information, by design.

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

#119

Post by neutronicus »

wasmperson wrote: post #27
tsimionescu wrote: post #12

> arrayref is a small crate of four macros. Why do so many languages fall into this horrible practice?

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…

The "npm-ness" of Cargo (centralized and standardized dependency management used at every opportunity) is generally pitched as one of the primary developer experience advantages over C++.

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

#120

Post by quotemstr »

insanitybit wrote: post #111
quotemstr wrote: post #109

Earlier quoted context omitted.

No, the reason people haven't been doing this -- and we've had technologies for ages -- is that it's a huge pain in the ass, a "tax", that it's hard to get developers inside a company to pay, much less participants in open source ecosystems. Look at how snap, flatpak, etc. provoke people to just turn off security rather than deal with breakages. A new language won't help because the problem is social, not technical.…

You can't simultaneously say that we've had the tech for years and also say that it doesn't work. We have not had the tech for years. x-plat sandboxing is extremely difficult, especially in a way that's performant. Sandboxing almost always involves having a dedicated, privileged service, due to how operating systems have designed things. It requires platform specific code. This is a technical problem and a social pro…

The technology works fine if you use it in a disciplined way. The problem is that people don't! You're necessarily going to break programs if you put them in restricted environments. That's not the same as the restriction technology not working properly.

> Sandboxing almost always involves having a dedicated, privileged service, due to how operating systems have designed things.

Or just invoking bwrap. Or sandbox-execute. There's no performance overhead. Complexity is minimal. Just read current Codex source code. It's not so bad. People have been making these sandbox tools for AI agents for years. Just need to apply sandboxing to all domains.

You want some kind of silver bullet that makes code "safe" without anyone having to change anything? To prompt for nothing? To use no IPC portal? That's not happening.

The people saying we need a new language or something are half right. We don't need a new language. A pure library solution is fine! But people do need to do work to make an ecosystem based on capabilities and least privilege to work. And we need to tell people who refuse to do this work to go to hell.

A new language is neither necessary nor sufficient. What we need is new set of balls.

Post reply on HN