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

321–330 of 529 posts

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

#321

Post by peesem »

cosmic_cheese wrote: post #311
fc417fc802 wrote: post #306

Earlier quoted context omitted.

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.

that seems unrelated to the security problem to me

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

#322

Post by josephg »

Pannoniae wrote: post #291
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…

The fallacy is assuming that standard != unchangeable. One can very simply....make breaking changes. Yes it will require some work to update but that's already the case when you upgrade library versions. The dependency hell doesn't help anyone here, the downside is much worse - lots of bloat, overgeneric libraries and awful supplychain security.

I’m a big fan of how C# handles this. The standard library is versioned like any other library. Your program is explicit about the major version of the standard library you’re pulling in. And all major versions of the standard library continue to work.

For rust, this would mean something like adding std = 1.0.6 to your cargo.toml. The advantage is it means the standard library can deprecate and replace features. Upgrading std is an explicit step by the developer. Annoying, but in the age of LLMs it should be pretty easy.

The one big question I can’t answer is what happens if your dependencies use a different version of std? Are std v1 Strings compatible with std v2 strings? Oof.

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

#323

Post by echelon »

Pannoniae wrote: post #292
afdbcreid wrote: post #283

Earlier quoted context omitted.

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.

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?

I don't want my language creating work for me. "Batteries included" is a feature of higher level languages. Rust is going to live for a very long time, probably beyond all of our lifetimes, and it needs to endure fads without picking up baggage and liabilities.

Rust could have a mandate where certain crates are "blessed" as recommendations. This could come with additional review, oversight, support, documentation, etc.

The Cargo.toml spec should have the ability to limit direct and transitive dependency count and depth. (As well as other things, like "nopanic" annotations/guarantees.)

The Crates.io repo should grow namespaces so we don't typo squat popular packages. It's much harder to miss organization names changing than package names changing.

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

#324

Post by mike_hearn »

ChrisSD wrote: post #231
mike_hearn wrote: post #213

Earlier quoted context omitted.

Worth noting that the JVM ecosystem doesn't have this issue because there is no notion of installing dependencies, and the package managers are just downloaders with nothing else. No build.rs equivalent. To solve the problem of native/C dependencies, they just bundle pre-compiled libraries as data files. Rust could do the same thing.

But then that shifts the issue. You've now got an opaque binary blob being injected into programs. What if it is malicious?

It may or may not be a problem depending on whether it's actually used, which is still better than "gets you instantly the moment you compile the app". A lot of codepaths and even whole libraries aren't invoked just because a program depends on them.

It doesn't really matter anyway, because nobody is reading anything in their dependencies before it gets downloaded. Malware can also be hiding in plain sight in source code, as this attack and many others shows.

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

#325

Post by josephg »

mightyham wrote: post #191
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…

True. And the rust standard library is pretty good. But I really wish we had a good, fast, small futures executor in std. And accompanying async variants of File and Socket and so on.

Async rust is a jungle of weird compatibility questions. People treat async runtimes like sports teams. (I know I do). I wish it were more like Nodejs where async is just built in.

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

#326

Post by mike_hearn »

burnt-resistor wrote: post #229
mike_hearn wrote: post #212

Earlier quoted context omitted.

Why not object capability languages: https://blog.plan99.net/why-not-capability-languages-a8e6cbd...

No. Object-oriented brings things many languages cannot use. Also, that was a tl;dr fluff blog with barely any examples.

All languages in mainstream use are imperative and at least somewhat object oriented, other than SQL. But many of those don't have what it takes to implement capabilities (too flexible/dynamic).

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

#327

Post by mike_hearn »

pie_flavor wrote: post #244
mike_hearn wrote: post #213

Earlier quoted context omitted.

Worth noting that the JVM ecosystem doesn't have this issue because there is no notion of installing dependencies, and the package managers are just downloaders with nothing else. No build.rs equivalent. To solve the problem of native/C dependencies, they just bundle pre-compiled libraries as data files. Rust could do the same thing.

ABI stability is significantly different in a VM language to a native language, and reified generics necessarily require source compilation. Binary-only development for Rust would be exactly as 'sort of not really' as C++, for exactly the same reasons. (There is also no notion of 'installing' dependencies in Rust, and build-time code being malicious isn't much worse than runtime code being malicious.)

But people say build.rs is used mostly to compile C dependencies, in which case the lack of ABI stability of Rust is neither here nor there.

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

#328

Post by pjmlp »

dwattttt wrote: post #299
pjmlp wrote: post #240

Earlier quoted context omitted.

Yeah, but I will take a not great library that works everywhere the compiler does, than be at the whims of which platforms are supported by 3rd party libraries. I can use most of the clunky Python, Java, .NET and if it must be, Go, standard libraries, than hunting down for dependencies with platform tier support and such.

Add more and more to a standard library, and you're going to start losing your "works everywhere".

Naturally there is a balance, still I think Java, .NET, Python, Go, Smalltalk, manage quite well, while having subsets to slim down when needed for specific deployment scenarios like embedded devices.

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

#329

Post by josephg »

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.

> there are no upsides (except, maybe, for faster compilation

Another big reason to put something in std is providing types for cross-crate compatibility. If I want to pass a String from one crate to another, I’m glad that string is defined in std so there’s an obvious type we can both use in our APIs.

C - for example - does not have this luxury. Everyone makes their own string type, and C APIs all need to translate strings at the api boundary. It’s super annoying.

It would be nice if we had a standard way in rust to declare a type as serialisable. Right now lots of crates have a serde feature flag to do this with serde. But (a) they need to put this behind a feature flag, since it adds a dependency on serde. And (b) this doesn’t work with other serialisation libraries.

The other big one is futures. There’s still no futures executor in std. Async crates have to decide if they want to tie themselves to a single executor (like Tokio) or be compatible. There is no async stream api in std. No async file api. And so on. It’s a compatibility nightmare.

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

#330

Post by brazukadev »

ptx wrote: post #138
crote wrote: post #19

Earlier quoted context omitted.

> Why do none of these hijacks embed runtime attacks? It seems like worming the build machines is the goal, rather than compromising downstream users. Developer machines are quite juicy targets. They tend to have all sorts of credentials lying around, so it often isn't too difficult to escalate from that to compromising AWS/GCP/etc. On top of that there's very little preventing a compromise. Developers are inherently…

Why are developers "inherently expected to run untrusted code"? Running untrusted code on developer machines seems like a terrible idea, given that it will compromise everything they build or deploy and (as you mentioned) all their credentials.

because cloning repos and installing dependencies is what developers do daily. 90% of more don't care or even know that doing so they are risking getting hacked.
Post reply on HN