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

311–320 of 529 posts

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

#311

Post by cosmic_cheese »

fc417fc802 wrote: post #306
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 don't see the problem with boost? Isn't that a perfect example of your well supported, community embraced option? I certainly feel much safer pulling something in from boost via the official debian repos than I do pulling a random package with npm or cargo or etc. Primarily I think the underlying concern has to do with the pathway for authoring code. When you have contributors whose submissions are gated with a rig…

> I don't see the problem with boost?

There are many issues that I've seen taken up with Boost, but my personal peeve is how it can make building projects that incorporate it a pain, both because of its sheer size but also because it can sometimes be difficult to appease with its own dependencies.

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

#312

Post by dwattttt »

cpuguy83 wrote: post #162
kevincox wrote: post #149

Earlier quoted context omitted.

Sandboxing the process only works well when the malware requires more capabilities than the software itself. So if your software needs to make HTTP requests and read the filesystem then the malware will be able to make HTTP requests and read the filesystem, which is enough for a ton of malware. Sure, maybe you can limit the directories it can access a bit and possibly some sort of network filtering, but it isn't a si…

The problem isn't the language here, it's cargo executing build.rs from dependencies which necessarily allows arbitrary code execution.

Running what you've built when you've added a malicious dependency also causes arbitrary code execution.

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

#313

Post by acje »

cube00 wrote: post #114

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

I have generated a report based on my own exposure to this attack today. The report was updated as the attack unfolded; https://acje.github.io/systems/arrayref_incident_record/

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

#314

Post by lelanthran »

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.

> There’s no reason why this can’t be replicated elsewhere.

It is replicated elsewhere and is not limited to Apple; I can do the same using a tech stack of perhaps 2x techs and very limited (manually added) deps. I'm thinking Lazarus, which comes with most things I'd need for most apps.

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

#315

Post by echelon »

cogman10 wrote: post #286
smw wrote: post #233

Earlier quoted context omitted.

I think maybe the right answer is to have a standardized, curated group of libraries pegged at some sort of LTS release that only backports security fixes. However, someone would need to pay for creating and maintaining this -- and then you wonder where the money would come from?

That or potentially fast tracking merging popular libraries into the standard library. Or at least concepts from popular libraries. Basically all the "most downloaded" crates on the Crates.io front page should be candidates for merging into the standard library. https://crates.io/

Good ideas are pulled into the standard library.

https://crates.io/crates/once_cell

https://doc.rust-lang.org/std/cell/struct.OnceCell.html

Not everything should be eligible for this treatment. Certainly not an HTTP library or something without extremely widespread applicability.

Nearly all of my projects used once_cell, so it's good to see that pulled in. I wouldn't want to see anyhow, thiserror, anything opinionated, or anything domain specific in the std. That's a weight you have to bear forever.

Remember how long Python 2 -> 3 took, and look at the ancient and awful stuff in Python 3's standard library. Rust is not the right language for this.

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

#318

Post by derefr »

fc417fc802 wrote: post #296
derefr wrote: post #255

Earlier quoted context omitted.

> That wouldn't be desirable in the case of a compromised crate: you don't want a download occurring at all. Sure you do; you just don’t want the crate to be made available to people trying to make use of the crate as regular downstream consumers. You still want the crate available for download for analysis . You especially want to be able to deterministically reproduce the vulnerable version of your software that yo…

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 download it would be a 401 (if unauthenticated) or 403 (if not on the whitelist) error response, which the packaging tooling would need to know how to handle.

(In any case, this “redacted” package state and my “exploited” package state could be two variants of the same logic, both following the same approach to locking/resolution, both requiring the flag to indicate that you understand what you’re doing and aren’t just going to run the resulting program. The only difference is that once you pass that flag, an “exploited” package would then just work, for anyone; while a “redacted” package would still have one more gate standing (server-side AAA) in the way.

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

#320

Post by derefr »

wavemode wrote: post #294
derefr wrote: post #255

Earlier quoted context omitted.

> That wouldn't be desirable in the case of a compromised crate: you don't want a download occurring at all. Sure you do; you just don’t want the crate to be made available to people trying to make use of the crate as regular downstream consumers. You still want the crate available for download for analysis . You especially want to be able to deterministically reproduce the vulnerable version of your software that yo…

I think "deleted" is still always going to have to be a package state, realistically. A package could contain spam, abuse, copyright infringement and/or illegal content. I don't mind malware being lumped in to that - the place to look up code for historical or analysis reasons ought to be version control, not crates.io

What about the place to look up packaged binary releases for historical or analysis reasons, esp. when the packaging system either builds such releases itself, or where it allows the submission of arbitrary build artifacts (where the build process that produced said artifact can be compromised in ways that have nothing to do with the source repo)?
Post reply on HN