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

421–430 of 529 posts

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

#421

Post by hnlmorg »

leecommamichael wrote: post #205
hnlmorg wrote: post #197

Earlier quoted context omitted.

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

Exploits can be shipped in any type of dependency. Remember the compression exploit that affected even SSH?

The problem is your solution depends on the honor-system. Ie “trust me, because I’m just a YAML mashaller. Why would I want to inject a crypto miner?”

That’s why package databases exist. They are meant to be centralised databases of peer reviewed and CVE checked resources. But Gos approach pushes all that responsibility onto each and every developer.

One thing it does get right, in my opinion, is removing the value of name squatting.

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

#422

Post by kibwen »

mattrighetti wrote: post #365
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…

> 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 total. Most of the things I wrote in Rust have less than 5 dependencies. Those 5 dependencies then depend on 20 other dependencies each. Those 20 dependencies have 2-3 other dependencies. And so on…

Counting the number of crates in the dependency graph in order to gauge exposure is a misunderstanding of how Rust works. In Rust the crate is the unit of compilation. Unlike in Javascript, the fact that a crate has dependencies on other crates does not mean the author pulled in random code written by someone else, it often just means that the author wanted to leverage crate-level compilation parallelism by splitting a large compilation unit out into several smaller ones.

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

#423

Post by throwawayqqq11 »

abhisek wrote: post #126
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...

This is exactly what PMG is designed for ie. install/build time process level sandboxing. It currently doesn't support cargo, but I believe the challenges are same. Here is my learning building PMG: Sandboxing is good when the workload is predictable, and the goal of sandbox is to guard against exploitation of vulnerabilities, like sandbox protecting chrome tabs (renderers). But unfortunately build scripts are not pr…

Then extend the list. We need isolated build envs AND deterministic builds, like nix does.

Id like to add project provided runtime capabilities/permissions (eg. apparmor profiles) to the list to.

Maybe the day will come, where projects not providing these things will be considered broken, like nix does.

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

#424

Post by kibwen »

pjmlp wrote: post #250
neutronicus wrote: post #119

Earlier quoted context omitted.

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

For those missing the npm like experience in C, they can use apt, yum, dnf, winget, nuget, conan, vcpkg.

In a large enough C codebase, you may even find yourself somehow using all of these simultaneously. :)

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

#425

Post by kibwen »

wahern wrote: post #193
weinzierl wrote: post #31

Earlier quoted context omitted.

Rich official standard library vs "import tons of libraries" are not the only two options. Java's standard library had arguably also been poor for a very long time and "import tons of libraries" just had not been practical for most of that time because the tooling and ecosystem for that did not exist yet. The solution was apache-commons and guava. Two large libraries with everything the developers heart desired and w…

Namespacing. Mandatory namespacing. It's an essential prerequisite for any kind of reputation building and managememt, before you even get into the gritty technical or security details. And it has to be mandatory. Top-level package names will always have more cachet. Developers are suckers for good package names, literal or imaginative. Plus it helps address, but by no means completely solves, name and typo squatting…

I'm not sure what namespacing has to do with anything here. Namespacing would not even remotely have prevented anything like the OP.

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

#426

Post by kibwen »

numbsafari wrote: post #385
rvz wrote: post #18

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

Maybe it wouldn't matter either way if people stopped putting untrusted executable code into basic build processes. You could get rid of a huge portion of the go standard library and have a massive ecosystem of leftpads, but the fact that `go build` can easily be run in off-line mode and doesn't execute any code other than the go toolchain itself, means you have a fundamentally more trustworthy ecosystem overall. Rus…

> the fact that `go build` can easily be run in off-line mode and doesn't execute any code other than the go toolchain itself

You can trivially run Cargo in offline mode, via the --offline flag. Nothing about this capability, in either Go or Rust, results in a more particularly trustworthy ecosystem.

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

#427

Post by kibwen »

wmedrano wrote: post #368
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…

Ok in theory, but I don't think it applies here. Maybe it does in a cultural way. Arrayref seems somewhat niche, but its kind of in the standard library as of Jan 2026 as std::slice::as_array https://doc.rust-lang.org/std/primitive.slice.html#method.as...

For the example given in the arrayref docs, I'd say you should be using std::slice::as_chunks, stabilized in 1.88: https://doc.rust-lang.org/std/primitive.slice.html#method.as...

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

#428

Post by wronex »

willtemperley wrote: post #404

Surely non-sandboxed build scripts are just a terrible idea. Both Cargo and npm should look at what Swift Package Manager (SPM) is doing. It’s not perfect but there’s a noticeable absence of supply chain attacks involving SPM, probably partly because it doesn’t use a mutable registry, but I suspect attacks are just more difficult. On the rare occasion a build script is involved it’s run in a sandboxed plugin.

Why would a malicious library author limit their maliciousness to the build script?

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

#429

Post by [deleted] »

wronex wrote: post #428
willtemperley wrote: post #404

Surely non-sandboxed build scripts are just a terrible idea. Both Cargo and npm should look at what Swift Package Manager (SPM) is doing. It’s not perfect but there’s a noticeable absence of supply chain attacks involving SPM, probably partly because it doesn’t use a mutable registry, but I suspect attacks are just more difficult. On the rare occasion a build script is involved it’s run in a sandboxed plugin.

Why would a malicious library author limit their maliciousness to the build script?

[deleted]
Post reply on HN