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

331–340 of 529 posts

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

#331

Post by jiggawatts »

rfgplk wrote: post #269
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.

Yep. Sorry for the spam, but look at this, compiling "yazi" from source (ie a relatively simple TUI file manager) 676 dependencies: Downloaded by_address v1.2.1 Downloaded block-buffer v0.12.1 Downloaded block-padding v0.4.2 Downloaded adler2 v2.0.1 Downloaded color_quant v1.1.0 Downloaded blowfish v0.10.0 Downloaded byteorder v1.5.0 Downloaded bytemuck_derive v1.12.0 Downloaded futures-sink v0.3.34 Downloaded bs58 v…

'bs58' jumped out at me as a random looking package name.

It implements the base58 encoding, which is used primarily by... Bitcoin.

I'd love to see the explanation of why "a TUI file manager" needs a crate closely associated with crypto coins and not much else.

It is precisely this kind of thing that makes Rust a no-go for most enterprises.

"I just want a CLI tool."

"Congratulations, your servers are mining crypto!"

PS: bs58 is maintained by one anonymous person and their package is used in just about every Rust crypto library and hence application. Compromise his account in the same manner as the 'xz tools' attack and you could still billions in crypto!

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

#332

Post by jopsen »

jfklgkdkdnn wrote: post #67
fidotron wrote: post #33

Doing software development outside of strict containerization, at the very least, looks increasingly prone to disaster. Yes, we can argue about the culture of package management (as some of us have with especially npm from day one), but it's done, and your colleagues or AI sidekicks cannot be trusted not to download whatever and try to build and run it. All you can do is limit the effective blast radius.

minimum-release-age

Or just burn some tokens scanning packages for bad behavior.

Granted some human will likely have to review it. Or packages flagged by Al could require users to explicitly allowlist them.

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

#333

Post by VorpalWay »

derefr wrote: post #318
fc417fc802 wrote: post #296

Earlier quoted context omitted.

I agree but think the problem is slightly more general. Consider that a package could be redacted not just due to exploit but also (among other things) for legal reasons, and that such reasons could be region specific. So a redacted package might or might not be available to manually download and some other metadata is desirable so that "audit" can notify you that you were compromised.

A package redacted for legal reasons should still be able to be built too! Presumably one or the other side of the relevant suit will need the package as evidence! I would suggest that such packages should simply require authenticated access + manual “write an email to ask to have your account be put on a whitelist”-driven authorization. Such a package would still be there (in its redacted state); but attempts to dow…

> A package redacted for legal reasons should still be able to be built too! Presumably one or the other side of the relevant suit will need the package as evidence!

This doesn't make sense if the legal reason is accidental release of secrets or PI, in which case you absolutely do not want to leave it up.

I'm not talking about things like github tokens here, those can be revoked. But actual secrets or PI where that isn't possible.

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

#334

Post by the8472 »

bel8 wrote: post #150
kibwen wrote: post #106

Earlier quoted context omitted.

The idea that Rust has a small standard library is a weird meme. Rust has an enormous standard library. Look at any Rust release and you'll see dozens of new library APIs added, and consider that Rust has about nine releases a year, meaning that Rust adds over a hundred APIs per year, and has consistently for the past ten years. Rust frequently adds things that obviate popular crates, most recently the cfg_if crate w…

It still lacks basic functionality like a JSON parser, regex, directory walker, rnd generator and cli arg parsing. I won't mention lack of date/time lib because that's complex and changes often. That's why projects end up with 100s of crates, sometimes 1000s. This might not be a well received fact in Rust community, but it's a fact nonetheless.

Ok, so I created an empty cargo project and added serde_json, regex, walkdir and rand. This added 28 crates, several of these from the same authors.

If the absence of these features caused 1000s of dependencies, then where are the remaining 972?

When I look at a project at work then what inflates the dependency tree is a combination of a whole webserver application stack plus SDKs consisting of dozens of crates. Those then pull in an async runtime or two, different HTTP clients, dozens of crypto crates and so on.

The crate count is a poor metric anyway since some subtree of dependencies is often provided by a single organization.

And I find it quite questionable that everything that's needed for an enterprise grade webserver stack should be part of the standard library, not even Java has that. Relatedly, cryptographers have failed to come up with a proven set of primitives, what's standard changes every few years.

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

#336

Post by sunshowers »

segphault wrote: post #195
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 stan…

Every Rust crate is heavily scrutinized these days using LLMs (which also caught this issue). The days when no one looked at dependencies are gone.

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

#337

Post by TZubiri »

cosmic_cheese wrote: post #289
TZubiri wrote: post #260

Earlier quoted context omitted.

I agree that building your own is hard and something that can be done by exceptional engineers, but software is famously a winner-take-all industry, even if the optimal strategy for lower percentile programmers and median programmers to import generic modules, as long as building your own results in the best product (which it does, whether importing frontend or backend modules, if you hand code something, it's going…

> Also the challenge of building a generic module is much larger than building your own. A generic module needs to have flexibility for many different options and integrations, when you build your own you build just what you need and tightly integrate it with the product True but I believe overestimated. Usually rather than building what's needed, what gets built is what is thought to be needed (often a substantially…

I think that even for core modules like an http server or client, but that's not the case and we don't need to get into that debate.

let's look at the actual package from OP

>https://docs.rs/arrayref/latest/arrayref/

>This package contains just four macros, which enable the creation of array references to portions of arrays or slices (or things that can be sliced).

I'm no rust programmer, but that doesn't sound like something that moves the needle. I talked about the ratio between value to risk being a relevant decision parameter, so getting infected by an http framework would be defensible, getting infected by adding this to a project to me is a PIP, and getting infected by installing leftpad or a custom cursor plugin in an IDE would be fireable.

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

#338

Post by TZubiri »

cesarb wrote: post #270
cosmic_cheese wrote: post #247

Earlier quoted context omitted.

I don't like the "bring your own" approach because unless one happens to be an absolute tour de force 10x engineer unstoppable god of a programmer (which most of us, myself included, are not), whatever you build is never going to be as well-rounded, fleshed out, and complete as something built by a larger organization, especially when it comes to UI libraries (which are monstrous projects if done right, e.g. meeting…

There's also the time factor. Something you build on your own will not have decades of development and polish behind it.

>https://docs.rs/arrayref/latest/arrayref/

>This package contains just four macros, which enable the creation of array references to portions of arrays or slices (or things that can be sliced).

The package in the OP is definitely not in the category of decades of development, it's closer to a leftpadism.

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

#339

Post by TZubiri »

segphault wrote: post #195
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 stan…

If those transitive dependencies are baked into the language runtime, how is anything materially different? You just shift the vector around.

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

#340

Post by tsimionescu »

vablings wrote: post #42
tsimionescu wrote: post #12

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

There are two reasons you might want to use a crate, The first being that you want to use a good solid implementation that you know someone has spent more time doing and works better than almost any solution you could integrate. The second is you don't want to spend time implementing that. Writing macros in rust is a pretty horrible experience but it's not difficult

The horrible practice is not writing libraries, it's having individual small packages like this crate that are handled by individual small authors, and ending up with huge webs of small dependencies.

The better practice is for bigger projects to form collecting such small utilities into larger utility libraries that have some organization, security practices, code reviews, etc. Good examples are Java's Apache Commons or C++'s Boost.

Post reply on HN