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

471–480 of 529 posts

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

#471

Post by a-french-anon »

pseudony wrote: post #457
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…

You can never please everyone , and some stdlibs can age like milk (see ocaml). Having libraries allow the community to explore rather than saddling it with a bad default. See the number of http server frameworks etc. The real solution here is not for the stdlib to become a black hole, swallowing up every half-way popular library a but rather for “rustaceans” to adopt a more security-conscious approach to writing pro…

You seem to be ignoring that most people who want off the infernal npm/cargo hamster wheel are conscious that it implies a bit of spoilt milk or moldy bread in exchange for stability and that they're fine with it.

The gains are just too numerous and important to reject the few rust spots on a "good enough" stdlib.

But well, the kind of people who nod a bit too much while reading https://boringtechnology.club/ aren't using Rust. They're on C99, ANSI CL, Ada, maybe Python, Perl or Tcl.

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

#472

Post by a-french-anon »

thatspartan wrote: post #456
lovehashbrowns wrote: post #394

Earlier quoted context omitted.

I think having production-grade implementations makes a huge difference also. Go’s net/http in the std lib feels like a good example of that, though I’m fairly new to go still. But it seems net/http still gets pretty big updates despite something like Chi being available as an external lib. Odin is doing this as well, even including raylib in the std lib. Odin is even more primed to keep you on the std lib as it does…

So I went to have a look at Odin and was mind blown at the lispiness in the hellope example. A list of operators defined as "program"; that are applied to the accumulator then printed. It's a striking first impression for me and I want to see what the Odin people have cooked up.

I wasn't when I saw they made the exact same stupid error as Python: if and switch are statements, so that you need a stupid ternary operator to do the same.

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

#473

Post by tome »

josephg wrote: post #469
nh2 wrote: post #467

Earlier quoted context omitted.

You have just reinvented "Safe Haskell" from 2012. It guarantees that pure functions are pure. https://www.microsoft.com/en-us/research/publication/safe-ha... https://downloads.haskell.org/ghc/latest/docs/users_guide/ex...

Oooh I didn't know that was a thing! Yes, I want this but in a fast, compiled systems language like rust.

Haskell is a fast, compiled systems language like Rust (or rather, Rust is like Haskell).

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

#474

Post by benj111 »

hbcdbff wrote: post #411
acje wrote: post #313

Earlier quoted context omitted.

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/

Slop

I don't want to read AI articles, but this isn't an article, this is one step up from a log file.

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

#475

Post by josephg »

tome wrote: post #473
josephg wrote: post #469

Earlier quoted context omitted.

Oooh I didn't know that was a thing! Yes, I want this but in a fast, compiled systems language like rust.

Haskell is a fast, compiled systems language like Rust (or rather, Rust is like Haskell).

Are you sure about that? My understanding is that Haskell programs generally run much more slowly than their C counterparts because of all of Haskell’s magic. Like lazy evaluation and memoisation and however Haskell manages memory.

Rust certainly borrows from Haskell. Like all good languages. But I’m not aware of Haskell beating rust in program performance & memory usage benchmarks.

SeL4 was first written in Haskell and proven correct in Haskell. Then, with a great many years of effort, ported to C and proven correct there. If Haskell were a viable systems language, I suspect the kernel would not have been converted to C.

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

#476

Post by xdavidliu »

kibwen wrote: post #275
Aeolos wrote: post #46

Earlier quoted context omitted.

The problem is that build scripts run automatically without user consent or intevention. `cargo add` is sufficient to compromise you, before you have a chance to even vet the code.

`cargo add` just modifies your Cargo.toml, it doesn't build anything.

https://shnatsel.medium.com/do-not-run-any-cargo-commands-on...

> any command starting with cargo can run arbitrary code when operating on an untrusted repository, and should be treated the same as cargo run.

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

#477

Post by dwroberts »

LtWorf wrote: post #418
dwroberts wrote: post #151

Earlier quoted context omitted.

My experience has been that it has a major advantage, in that freeze + offline actually work properly. You can collect the dependencies you need once, put them in version control and never ever talk to remote registry again

You mean leave all CVEs open?

I guess that’s more of a problem if you use all-encompassing frameworks, but normally the things I’m using are very small components where the CVEs either don’t exist or are inconsequential/unexploitable for the programs I’m building

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

#478

Post by LtWorf »

dwroberts wrote: post #477
LtWorf wrote: post #418

Earlier quoted context omitted.

You mean leave all CVEs open?

I guess that’s more of a problem if you use all-encompassing frameworks, but normally the things I’m using are very small components where the CVEs either don’t exist or are inconsequential/unexploitable for the programs I’m building

So you don't track them, have no way of tracking them and just hope for the best. I hope no customer of yours asks for an SBOM :D

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

#479

Post by dwroberts »

LtWorf wrote: post #478
dwroberts wrote: post #477

Earlier quoted context omitted.

I guess that’s more of a problem if you use all-encompassing frameworks, but normally the things I’m using are very small components where the CVEs either don’t exist or are inconsequential/unexploitable for the programs I’m building

So you don't track them, have no way of tracking them and just hope for the best. I hope no customer of yours asks for an SBOM :D

Updating every dependency for every kind of CVE is a brute force method for people and organisations that don’t understand the attack surface of the programs they’re producing

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

#480

Post by throwaway894345 »

bluGill wrote: post #133
throwaway894345 wrote: post #116

Earlier quoted context omitted.

Why does every build have the ability to run arbitrary code by default in the first place? That seems like something you should opt into only under very specific scenarios and even then it should probably be built around a WASM sandbox or microVM (as the parent suggested).

Because many many builds end up doing something just a little weird that the build system cannot handle by default. Ideally the build system would be fully property/dependency based and so it wouldn't have to run arbitrary code. In the real world everybody has something weird about their build that the build system cannot make work. This is partially because for nearly every project the build system is something they…

I mean, I understand the need for an escape hatch, but it’s strange to me that it’s the default and that it’s unsandboxed. Feels like build scripts should be treated like CGo in Go—a rare escape hatch that people strongly try to avoid so that downstream builds are better. To that end, Go doesn’t even have macros or code generation and it gets by reasonably well without any build scripts should support—I understand that Rust’s emphasis on systems programming probably drives more scenarios where build scripts are genuinely necessary, but I strongly suspect that, as with C and C++, making it easy for people to do weird stuff probably drives a lot of people to think they need to do weird stuff.
Post reply on HN