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

191–200 of 529 posts

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

#191

Post by mightyham »

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 open source development.

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

#192

Post by lesuorac »

rirze wrote: post #167
0cf8612b2e1e wrote: post #160

Earlier quoted context omitted.

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

which, as painful as it may be, is ok. Better to have a safe functional stdlib library than a exposed external crate (which then asks the question; what's the replacement...)

Those aren't the only two choices.

We also have the classic example of PHP with numerous not safe stdlib ways to use mysql.

To me the answer is still to vendor your dependencies and don't be on the bleeding edge of updates unless you're willing to invest the time into validating them.

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

#193

Post by wahern »

weinzierl wrote: post #31
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…

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 understand people and groups can run their own crates.io-like repository, but that's a tangential aspect. Even if this were ubiquitous, you'd still want mandatory namespacing. You want provenance, or at least intended/nominal provenance, to be as transparent as possible, not implicit or buried. By no means a complete solution, but an important foundation for better technical and culture patterns.

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

#194

Post by leecommamichael »

hoppp wrote: post #181

The rust ecosystem is going to be hit by malware just like the NPM ecosystem. I have been saying it for years. They made the same mistakes or even worse mistakes because all it takes is a compromised serde to take the entire ecosystem down.

Here's a suggestion, do you think it could be this simple? If you write a package-manager, don't execute any of the downloaded code in an automated fashion. No hooks, no build-time metaprograms. If your language _needs_ metaprogramming to function, it's a huge secondary issue that I don't know how to solve. You can try to make a meta-program annotation which disables side-effects, but the metaprogram ultimately must write memory which expands the amount of code generated. All risk is introduced when the person downloading cannot preview the content in a safe place.

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

#195

Post by segphault »

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 is spot on. I am extremely uncomfortable with the large number of transitive dependencies that end up in pretty much any non-trivial rust application. No amount of memory safety will save us if a tiny, ubiquitous library that nobody scrutinizes because it’s nested eight layers down the dependency graph gets compromised.

I think Go apps tend to have better dependency hygiene because the language has a better standard library, which results in better culture around dependencies.

I also think it’s frustrating that both cargo and npm totally ignore the decades of prior art from Linux distributions that have figured out good ways to improve dependency management. We’d be in better shape if there was a community curated subset of known-good dependencies that are release-managed together that the broader ecosystem could build on, sort of like Ubuntu having “main” and “universe”.

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

#196

Post by mabini »

swiftcoder wrote: post #105
mabini wrote: post #87

Earlier quoted context omitted.

[flagged]

> Just wondering, whenever things go wrong with Rust - why do you all (Rust devs) point the finger at JavaScript? I know it is almost a sport to point fingers at the "evil rust evangelists" on HN at this point, but a quick look at the fnoef's comment history would show you that they are not a rust person. Your account, on the other hand, is a sock puppet created specifically to bitch about rust. Pot, meet kettle?

[flagged]

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

#197

Post by hnlmorg »

leecommamichael wrote: post #189
hnlmorg wrote: post #187

Earlier quoted context omitted.

Go took the same approach and ended up having to implement a halfarsed one when everyone started implementing their own.

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 think the real issue is malicious packages entering package ecosystems. Whether your package manage executes on downloads or not is moot because you’ve still got untrusted code sat in your project imports, just waiting to be accidentally executed.

> I guess you're saying, "they had to" meaning they should've seen the need and provided it? I'll say this to that (imagined) take; plenty of useful software was made without it, and they got the job done when they knew the absolute most about what a good solution would need. I totally understand being annoyed at the fact that this is the story of every evolution in Go.

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.

And really what they built was the bare minimum to manage package version pinning and updates. But it has none of the visibility that central package repositories have. So how do you know if a Go package has been compromised when the only source of truth is the compromised origin?

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

#198

Post by thayne »

quikoa wrote: post #182
hbbio wrote: post #79

Rust suffers from the same faults as the JS ecosystem. Any significant crate imports hundreds if not thousands of dependencies. The probability that one of the authors gets targeted by AI-assisted attacks is just too high. Also most of these dependencies provide a breadth of features that the end package does probably not need.

A language without a large stdlib pushes this that functionality into (transitive) dependencies. I hope more language will adopt batteries included approach.

No stdlib will ever include all the "batteries" you need. And large stdlibs have their own set of problems, like stagnation, tying the library version to the language version, backwards compatibility garantees preventing evolution, and either needing a wide range of domain experts to maintain it, or having developers maintain components they don't have a deep understanding of.

I think the sweet spot is having an ecosystem of "blessed" libraries that are reviewed for security and quality, but are versioned independently of the language, and maintained by subject matter experts.

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

#200

Post by maximegarcia »

thayne wrote: post #185
cube00 wrote: post #180

Earlier quoted context omitted.

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

It wasn't yanked, it was fully removed. They did that because a yanked package can still be used. And in this case there weren't any downloads, so it is unlikely the malicious package was actually used.

Call it how you want, the point is that it should not disappear like this. Maybe yanked has the meaning you said, but in Ruby yanked has the meaning OP said and that is what we want.

How to call it then : Yanked hard vs yanked soft ?

Post reply on HN