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

301–310 of 529 posts

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

#301

Post by [deleted] »

afdbcreid wrote: post #283
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.

People confuse what they want. They do not want a big stdlib. The downsides are real (the stdlib cannot make breaking changes), and there are no upsides (except, maybe, for faster compilation, since std comes precompiled). They want more official crates (e.g. `regex` and `libc` are official crates, maintained by the Rust project). And the Rust project does not oppose to that, it just doesn't have the funding.

[deleted]

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

#302

Post by Pannoniae »

afdbcreid wrote: post #295
Pannoniae wrote: post #292

Earlier quoted context omitted.

Who said a standard library can't make breaking changes? That used to be a norm some time ago. There are upsides, your program is smaller, better security because a random kid can't pwn your deps, quality and interoperability. What's not to love?

> Who said a standard library can't make breaking changes? The std making a breaking change is the language making a breaking change. Most mainstream languages guarantee stability, certainly Rust. > your program is smaller How so? It doesn't matter if the code is in std or a crate. > better security because a random kid can't pwn your deps, quality and interoperability That's exactly what I said: you don't need bigge…

>Most mainstream languages guarantee stability, certainly Rust.

That's their mistake, right there... When you're upgrading software, you presumably want a better version. You can't have something better without changing it. It's a logical contradiction.

>It doesn't matter if the code is in std or a crate. It very much does because you don't need 95% of the random stuff in the crates. Even for something like rand, you need an xorshift and that's roughly it. 25 lines of code, sorted. You can even write it as a copypaste "dependency" without much fuss in practically any language. That, versus importing a whole rand library with lots of different algorithms, deps on crypto, tests, OS random-based seeding, customisability, etc.

>you just need more official crates

I guess that's one solution but it would probably just be a better idea to split std in two SLAs, one is guaranteed for core stuff i.e. the status quo, one is YMMV.

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

#303

Post by fc417fc802 »

conradludgate wrote: post #290
cogman10 wrote: post #281

Earlier quoted context omitted.

I believe what's being suggested is that `cargo audit` should be a part of cargo rather than an add on. You'd obviously already have cargo installed, which means you should be able to run a command against cargo to see if you are currently exposed to any security problems. Even if it's not the current "audit" add on.

As someone using bazel at work, the find script was much more amenable to me trying to audit our usage - we don't use cargo, so no cargo cache or cargo audit, but I can still figure out whether a particular package was downloaded.

If you're using a different tool then it falls to that tool to address the same problem. The point is that I shouldn't have to already know that a compromise has occurred and then go looking for it manually. The tooling should automatically start shouting at me very loudly that something happened with one of the packages I'm using.

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

#304

Post by __david__ »

teach wrote: post #280
__david__ wrote: post #256

Earlier quoted context omitted.

I think Go ends up with fewer dependencies mostly because there is more friction in finding them. With rust (and npm) you just "cargo search xxx", then "cargo add xxx". Go makes you web search and poke around github looking for something. It's not onerous or anything, but just that extra step slows things down just a bit. C projects tend to have the least because it's even more annoying to add them and you have to cr…

Actually I think this is more of a culture thing. Or maybe "is also" a culture thing. One of the core tenets of early Go was the maxim "a little copying is better than a little dependency". Probably because of this stance, they didn't even HAVE a dependency-management solution for years I strongly agree the fewer dependencies the better, on average.

Perhaps, but I think it depends on where the Go devs are coming from. In my experience the lack of proper dependency management in older versions of Go didn't really lessen dependencies, it just made teams have to deal with annoying $GOSRC issues. But then I worked at a place where the devs used PHP (w/composer) and node before Go was introduced.

Personally I came from a C background so I tended to use deps more sparingly.

In the end it's a bit of a balancing act—lots of dependencies is a larger opportunity for these kind of supply chain attacks to affect you. Copying stuff into your repo protects you from that, but it also makes it way more likely that you'll miss security fixes, unless you're actively looking for them. Re-implementing what you need is also viable but it slows down the dev process.

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

#305

Post by nottorp »

fwlr wrote: post #285

From the article: “[for Windows victims,] the [malicious] build script [fetches the attacker’s remote payload,] writes [it] to %TEMP%\rust-setup.ps1 and starts [it] through a VBScript launcher under wscript.exe, with a comment in the source explaining why:” And the comment is: // ShellExecute via WScript escapes Cargo's job object; spawned children otherwise // keep the build script (and `cargo build`) waiting until…

Eh, just because the likes of Anthropic are only threatening you with their latest model, it doesn't mean older models can't do exploits...

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

#306

Post by fc417fc802 »

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 rigid third party process and where that third party is the one responsible for curating the code (as opposed to the author also being the curator as well as the publisher) then you have the possibility to catch a lot of wrongdoing before it succeeds.

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

#307

Post by jaen »

leecommamichael wrote: post #194
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…

The only safe solution is to review all the code's changes (or trust someone else to do it).

Forbidding compile/build-time shenaningans is trivially bypassable and has already been bypassed in the NPM ecosystem by just making the library code itself (not the build scripts) malicious - eg. do the bad thing when the code is loaded/tested, assuming the language has static constructors.

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

#309

Post by jaen »

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.

(as I and others have mentioned in the thread): The attacker can just move the malicious code from build.rs to lib.rs (ie. build-time -> test/execution-time).

Then the problem is the language, as the grandparent observes.

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

#310

Post by mswphd »

smw wrote: post #233
echelon wrote: post #223

Earlier quoted context omitted.

Python is batteries included, but all the batteries have corroded. Look at C++'s long in the tooth STL. You don't want to marry a language to fast aging libraries you have to support for eternity. Better libraries always naturally emerge. Rust's decision here is fine. The only thing I'd like to see is the ability to programmatically limit transitive dependency count or depth in Cargo. I'd also like crates to specify…

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?

someone tried doing this for rust, but the reaction was that it was vibe-coded/low quality.

https://github.com/rust-stdx/stdx

https://news.ycombinator.com/item?id=48571266

Note that there are baby versions of this that are uncontentious, for example

https://blessed.rs/crates

this is missing the LTS release. but it is a curated group of libraries that are relatively uncontentious to recommend.

Post reply on HN