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

201–210 of 529 posts

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

#201

Post by fidotron »

hnlmorg wrote: post #190
jonahx wrote: post #95

Earlier quoted context omitted.

Proper and easy to use support for sandboxes at the OS level, or better yet capabilities, seems like the only long term solution. Many things I run I want to limit to r/w a single dir, and to have to request permission to make network calls.

Two problems with this: 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. 2. Even if there were, if you’re compiling untrusted code then why would you trust the built output? If you’re building the create then I’d argue that any preventative steps afterwards is akin to closing the barn door after the horse has already bolted.

> 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust.

Yeah, let's hold up the entire world of offensive cybersecurity capability while you work on that. Sure they will wait.

> 2. Even if there were, if you’re compiling untrusted code then why would you trust the built output?

You don't. You sandbox the hell out of it too.

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

#202

Post by leecommamichael »

hnlmorg wrote: post #197
leecommamichael wrote: post #189

Earlier quoted context omitted.

Has Go not had the most secure ecosystem? What is your critique of their approach? Is it not the case that `go get` is the only one which doesn't even provide a way for the person downloading to run the downloaded code until it is actually executed by the consuming codebase? That seems pretty sound by comparison. I guess you're saying, "they had to" meaning they should've seen the need and provided it? I'll say this…

> What is your critique of their approach? It’s half arsed, brittle and far from user friendly. > Is it not the case that `go get` is the only one which doesn't even provide a way for the person downloading to run the downloaded code until it is actually executed by the consuming codebase? If you’ve added the package to your imported then odds are your next step is going to build it. Thus negating any benefit. I thin…

Thanks for the thorough reply. I personally haven't experienced brittleness/unfriendliness, but I have only written around 10k lines of Go. Not exactly a power user, but I like to think I understand it.

> If you’ve added the package to your imported then odds are your next step is going to build it. Thus negating any benefit.

I actually think this is the benefit! I don't need to go to a website to see what changed, I can just have a look at the code. The best dependencies have a changelog. Ideally I can look at a diff.

> I think you’re being too charitable here. I think Russ Cox just didn’t want a package manager because C doesn’t have one. But ended up relenting after everyone nagged the Go team for years afterwards.

That's entirely possible.

> So how do you know if a Go package has been compromised when the only source of truth is the compromised origin?

Fair point, and probably worse in this future we're in now that NIST is drowning in CVEs and has turned away from some share of them.

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

#203

Post by eminence32 »

cube00 wrote: post #180
landr0id wrote: post #174

Earlier quoted context omitted.

[3] is no longer true. They're definitely not unprepared for an incident like this. It's not the first time they've done it and they published an update to their process in Feb: https://blog.rust-lang.org/2026/02/13/crates.io-malicious-cr... Not having an advisory INSTANTLY available isn't a sign of a decaying org. Chill.

> They're definitely not unprepared for an incident like this. We shouldn't need to resort to pasting `find` commands [1] into the shell from blog posts to tell if we're compromised. `cargo audit` should be reporting if these packages have been downloaded. The "What you need to do" section of the blog should be run `cargo audit` > Not having an advisory INSTANTLY available isn't a sign of a decaying org. Chill. The G…

> We shouldn't need to resort to pasting `find` commands [1] into the shell from blog posts to tell if we're compromised.

I know you recommended `cargo audit`, but that is not nearly as universally installed as `find`. And as far as I know, cargo-audit has to be run within a project directory? Can it be run outside of the context of a project and scan the cargo registry cache?

I personally appreciated having the `find` command:

* It very clearly indicates where to look (my cargo registry cache)

* It very clearly indicates what files to look for (a list of wildcards)

* It's something that I can easily review and then copy/paste into my terminal

* I can very easily adapt it to my particular environment (perhaps into a `fd` invocation if I'm on Windows, or perhaps adapt it to scan all home directories on my system), or feed these file names into some other vulnerability scanner

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

#205

Post by leecommamichael »

hnlmorg wrote: post #197
leecommamichael wrote: post #189

Earlier quoted context omitted.

Has Go not had the most secure ecosystem? What is your critique of their approach? Is it not the case that `go get` is the only one which doesn't even provide a way for the person downloading to run the downloaded code until it is actually executed by the consuming codebase? That seems pretty sound by comparison. I guess you're saying, "they had to" meaning they should've seen the need and provided it? I'll say this…

> What is your critique of their approach? It’s half arsed, brittle and far from user friendly. > Is it not the case that `go get` is the only one which doesn't even provide a way for the person downloading to run the downloaded code until it is actually executed by the consuming codebase? If you’ve added the package to your imported then odds are your next step is going to build it. Thus negating any benefit. I thin…

Ultimately I think devs need to think about their dependencies and decide which ones get pinned and a serious review before pulling. If the thing has got binaries, it gets a serious review. If it does anything with cryptography, it gets a serious review... etc.

I don't think automatic updating is a good idea at all. It's just the honor-system, and trust is a security flaw.

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

#206

Post by robhlt »

kibwen wrote: post #155
swiftcoder wrote: post #93

Earlier quoted context omitted.

build.rs by design can run absolutely anything. There tons of build.rs scripts that invoke a whole-ass C compiler toolchain to build and link C dependencies... It isn't so much a question of sandboxing build.rs, as fundamentally changing the way that foreign dependencies are integrated into the rust toolchain (i.e. moving from a rust-centric system like Cargo to something more general like buck2)

The vast and overwhelming majority of build scripts are building C code, so the other solution is to move away from integrating with C dependencies to native Rust dependencies, in which case adding friction to build scripts would be less noticeable.

Just denying write access outside the build directory and denying network access would go a long way and won't break pretty much any well-behaved build systems.

Any C library that's also packaged by debian supports being built under these conditions because it's required for everything except non-free packages: https://www.debian.org/doc/debian-policy/ch-source.html#main...

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

#207

Post by bigstrat2003 »

Aeolos wrote: post #107
burnt-resistor wrote: post #91

Earlier quoted context omitted.

Never going to work. Crates must be audited for behavior before use.

cargo add + rust-analyzer instantly executes build.rs before you have a chance to audit the code. Cargo, please PLEASE give me a way to disable third-party build.rs and whitelist the ones I need. And please loudly mark any update that adds a build.rs where there was none before.

So, don't add dependencies before you audit the code? That seems like a pretty reasonable ask to me.

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

#208

Post by bigstrat2003 »

0cf8612b2e1e wrote: post #160
yoyohello13 wrote: post #85

Earlier quoted context omitted.

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.

On the other hand, there are some bad Go standard libraries that are frozen in time.

Which isn't actually a problem. You can ignore the bad standard library and use something different.

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

#209

Post by cosmic_cheese »

mightyham wrote: post #191
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…

Rust has a sizable and well featured standard library at this point. I think it would be absurd to claim that the base language is "near-unusable" if you are using it for system programming, which is its intended use case. Huge standard libraries make sense for Java, Go, Apple platform etc. because they are developed by giant enterprises that can manage the overhead. Thinner modular systems are a more natural fit for…

It’s being used for a wide variety of other purposes however, and so perhaps it’s time to adapt to that reality.

While overhead is a real concern, I think it’s often blown out of proportion. Once a language achieves a certain baseline of stability and isn’t in constant flux and the standard library matures, changes become infrequent and maintenance load is low. The work is heavily front-loaded.

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

#210

Post by jonahx »

hnlmorg wrote: post #190
jonahx wrote: post #95

Earlier quoted context omitted.

Proper and easy to use support for sandboxes at the OS level, or better yet capabilities, seems like the only long term solution. Many things I run I want to limit to r/w a single dir, and to have to request permission to make network calls.

Two problems with this: 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. 2. Even if there were, if you’re compiling untrusted code then why would you trust the built output? If you’re building the create then I’d argue that any preventative steps afterwards is akin to closing the barn door after the horse has already bolted.

> There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust.

I said OS level. It's something I should easily be able to do via the OS capabilities that would work for rust, npm, etc.

I would use it not only for rust builds but for nearly every app on my computer.

Post reply on HN