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

481–490 of 529 posts

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

#481

Post by nathan_compton »

hnlmorg wrote: post #419
fidotron wrote: post #201

Earlier quoted context omitted.

> 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. Yeah, let's hold up the entire world of offensive cybersecurity capability while you work on that. Sure they will wait. > 2. Even if there were, if you’re compiling untrusted code then why would you trust the built output? You don't. You sandbox the hell out of it too.

> Yeah, let's hold up the entire world of offensive cybersecurity capability while you work on that. Sure they will wait. Nice sarcasm but you’re not actually addressing a solution to the problem I raised. > You don't. You sandbox the hell out of it too. So you’re now saying it’s ok to have exploits compiled into your application as long as it’s sandboxed? I wonder how customers of your application feel about that? I…

This response seems disingenuous. It was never implied it was ok to have exploits in the compiled software, only that the blast radius is smaller if the compiled code is also sandboxed.

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

#482

Post by tome »

josephg wrote: post #475
tome wrote: post #473

Earlier quoted context omitted.

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…

Yes, I'm sure about that. I said that it is a systems language, not that it is as fast as C! I don't mind if your terminology excludes Haskell from being a systems language, as long as it also excludes Go. They are both managed, garbage collected, fast languages.

> Like lazy evaluation and memoisation

Yes, that causes performance impact. If you don't want the performance impact then don't write code that uses those behaviors. Sure, that rules out large parts of the ecosystem, but I said Haskell was a systems language not that its ecosystem was generally suitable for systems programming.

> however Haskell manages memory

No, Haskell's memory manager is world class, with two (at least) tunable garbage collectors.

> But I’m not aware of Haskell beating rust in program performance & memory usage benchmarks

Nor am I!

> If Haskell were a viable systems language, I suspect the kernel would not have been converted to C.

I suspect they converted it to C because you can't write a kernel in a managed language with a garbage collector.

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

#483

Post by LtWorf »

dwroberts wrote: post #479
LtWorf wrote: post #478

Earlier quoted context omitted.

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

And vendoring without having any idea of what is in there and doing no monitoring is peak engineering?

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

#484

Post by fidotron »

hnlmorg wrote: post #419
fidotron wrote: post #201

Earlier quoted context omitted.

> 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. Yeah, let's hold up the entire world of offensive cybersecurity capability while you work on that. Sure they will wait. > 2. Even if there were, if you’re compiling untrusted code then why would you trust the built output? You don't. You sandbox the hell out of it too.

> Yeah, let's hold up the entire world of offensive cybersecurity capability while you work on that. Sure they will wait. Nice sarcasm but you’re not actually addressing a solution to the problem I raised. > You don't. You sandbox the hell out of it too. So you’re now saying it’s ok to have exploits compiled into your application as long as it’s sandboxed? I wonder how customers of your application feel about that? I…

> Nice sarcasm but you’re not actually addressing a solution to the problem I raised.

Are you not concerned about an asteroid impact rendering you extinct during your next Rust build? Why not? That's the same level of relevance as your supposed concern.

> So you’re now saying it’s ok to have exploits compiled into your application as long as it’s sandboxed?

You need to act like it is compromised in all cases, just like everything else.

> I wonder how customers of your application feel about that? I’m certainly not going to be entering my bank details into your ecommerce platform (to give just one obvious example why your suggestion wouldn’t work).

So your version is "we trust everyone and don't verify anything". Yeah, that's going to work. By your "logic" firewalls wouldn't be necessary.

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

#485

Post by afdbcreid »

gigaritee wrote: post #445
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.

This is not true. I want a big standard library and I am more than willing to deal with the downsides just like i have with python. Batteries included ia the only sane way to do programming languages.

You haven't provided any reason why you want a batteries-included std, while I did include a rebuttal of reasons people commonly claim.

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

#486

Post by cosmic_cheese »

kelnos wrote: post #408
cosmic_cheese wrote: post #379

Earlier quoted context omitted.

> Maybe std should pick up the best crates from the community and bring them in house? This might be a good idea. But also maybe not. Since serde came out, several other crates have found ways to crush its performance numbers. Often by 2-5x if memory serves. What a relief we didn’t immortalise the slow version of serde, right? I think periodically rolling in the best crates is the way. Don't immortalize anything, tho…

> Don't immortalize anything, though. Always reserve the freedom to swap out integrated crates when something better rolls around. That's a non-starter, though. Once it's in std, it's not an "integrated crate", it's in std , just like any other part of it. Removing it is a breaking change, and I don't want a new incompatible Rust major version every year or two (or even five or ten, honestly). (Of course, Rust has ed…

I don’t quite get this mentality.

Yes, it’s annoying to have to make fixes around my codebases periodically, but to me that’s a hell of a lot less annoying than having to pull in a mile long list of dependencies to do anything of consequence. It’s also better than the bad parts of the language being frozen in time forever.

Apple breaks things with Swift not constantly but on occasion and while there’s some griping around it, it’s not a big deal. We make the needed changes and move on, knowing it’s enabling improvements that will be nice to have.

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

#487

Post by vablings »

tsimionescu wrote: post #340
vablings wrote: post #42

Earlier quoted context omitted.

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…

Both the examples you provided fit into the first scenario described. See libs by dtolnay for useful tools

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

#488

Post by Manishearth »

survirtual wrote: post #463
Manishearth wrote: post #382

Earlier quoted context omitted.

The response was managed by the security-response team working with the infra team and the Rust Foundation's Security engineer. Tobias from the crates.io team was also involved but on vacation so it was not as active. This is normal. What makes you say we were unprepared? We have been deleting malicious crates for a while. This is the first time those crates have wormed their way into an actual real crate that people…

The crates.io page and version history should have an entry, like red with an ! and a cross through with an advisory note explaining the security issue, accessible via the api as well so it is clear what happened. The main crate entry should also contain a security advisory at top. I looked at the crate and it just looked normal; I had to dig to find the exact impact surface, and if I wasn't informed via secondary me…

cargo-audit is the automated mechanism you are looking for

The crate does have an advisories/"security" page on crates.io.

We could try and show the existence of a security-deleted crate on the page. This is not a priority for anyone, and I remain unconvinced that it needs to be (not that that is my decision anyway). File an issue and make your case to the crates.io team.

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

#489

Post by hnlmorg »

nathan_compton wrote: post #481
hnlmorg wrote: post #419

Earlier quoted context omitted.

> Yeah, let's hold up the entire world of offensive cybersecurity capability while you work on that. Sure they will wait. Nice sarcasm but you’re not actually addressing a solution to the problem I raised. > You don't. You sandbox the hell out of it too. So you’re now saying it’s ok to have exploits compiled into your application as long as it’s sandboxed? I wonder how customers of your application feel about that? I…

This response seems disingenuous. It was never implied it was ok to have exploits in the compiled software, only that the blast radius is smaller if the compiled code is also sandboxed.

Smaller maybe. But it’s still an unacceptable risk. I refer you back to my example of compiled code being used by customers.

Arguing that compromised code is safer when sandboxed really misses the real problem: that you’re running compromised code in the first place. Hence my analogy of closing the barn door after the horse has already bolted.

What we need is to ensure we have stronger safeguards in place to prevent bad code from reaching build pipelines. If it’s in the build pipelines then we’ve already lost.

I get why people argue about sandboxing, it’s an easier problem to solve. But you still end up with a compromised artefact which you cannot ship. So the benefit is negligible.

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

#490

Post by hnlmorg »

fidotron wrote: post #484
hnlmorg wrote: post #419

Earlier quoted context omitted.

> Yeah, let's hold up the entire world of offensive cybersecurity capability while you work on that. Sure they will wait. Nice sarcasm but you’re not actually addressing a solution to the problem I raised. > You don't. You sandbox the hell out of it too. So you’re now saying it’s ok to have exploits compiled into your application as long as it’s sandboxed? I wonder how customers of your application feel about that? I…

> Nice sarcasm but you’re not actually addressing a solution to the problem I raised. Are you not concerned about an asteroid impact rendering you extinct during your next Rust build? Why not? That's the same level of relevance as your supposed concern. > So you’re now saying it’s ok to have exploits compiled into your application as long as it’s sandboxed? You need to act like it is compromised in all cases, just li…

> Are you not concerned about an asteroid impact rendering you extinct during your next Rust build? Why not? That's the same level of relevance as your supposed concern.

That’s a strawman argument and you’re still dodging the question.

> You need to act like it is compromised in all cases, just like everything else.

No. I act like compromised code is a legitimate risk regardless of how well your build pipeline is sandboxed.

I don’t understand why this is a hard concept for you to grasp.

> So your version is "we trust everyone and don't verify anything". Yeah, that's going to work. By your "logic" firewalls wouldn't be necessary.

That’s the literal opposite of my point (as well as another strawman).

Post reply on HN