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

141–150 of 529 posts

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

#141

Post by ux266478 »

mabini wrote: post #87
fnoef wrote: post #73

Oh, so it's not only "JavaScript bad and npm bad". Apparently, if your language uses third party dependency registry, you are prone to malicious code, regardless if it's Javascript or not. Use containers for development. And reduce the amount of third party deps you import into your projects. This is only going to get worse.

[flagged]

You're literally replying to someone saying npm is unfairly called out.

Rust developers aren't the ones who have problems with it. Otherwise they likely wouldn't be using Rust in the first place. I don't see anyone saying JavaScript is worse about it either, more that they're the same.

Why are you getting so defensive about it?

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

#142

Post by never_inline »

aftbit wrote: post #4

Why do none of these hijacks embed runtime attacks? It seems like worming the build machines is the goal, rather than compromising downstream users. It seems like we should be building and testing everything in bubblewrap or some other sandbox going forward.

How do we know they don't? Who is going to read the source for all these micro packages?

You might assume we are able to detect all malicious behavior at runtime. But "stuxnet" and more recently, the xz compromise say otherwise. What if a not-so-popular crate deep in the dependency chain subtly introduced a LPE in it's code?

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

#144

Post by skydhash »

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 don't mind code execution as even make has shell scripting embedded, same thing with meson. My issue is with network access to download random stuff without it being declared somewhere and signed.

I'm using OpenBSD and the ports system set up two users `_pbuild` and `_pfetch` for building packages. The first one is for building and the sample `pf.conf` (firewall) forbid it from accessing the network. The second does fetch the files , but it's declarative with every files listed and signed. Even for languages like go and rust.

Fetching files while building is the bad idea there.

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

#145

Post by lobofta »

Panzerschrek wrote: post #76
jakubadamw wrote: post #41

Cargo desperately needs sandboxing for build.rs scripts. It’s been attempted before, but didn’t go very far¹. ¹ https://rust-lang.github.io/goals/2024h2/sandboxed-build-scr...

Sandboxing for build scripts can't work properly. If you sandbox too much, some necessary stuff can't be done. If you sandbox too little, it has no practical value.

So let each build script define its own level of sandboxing and then users can determine whether they are okay with that level or not, e.g. `cargo build --sandbox-level=...`

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

#146

Post by bluGill »

skydhash wrote: post #144
bluGill wrote: post #133

Earlier quoted context omitted.

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 don't mind code execution as even make has shell scripting embedded, same thing with meson. My issue is with network access to download random stuff without it being declared somewhere and signed. I'm using OpenBSD and the ports system set up two users `_pbuild` and `_pfetch` for building packages. The first one is for building and the sample `pf.conf` (firewall) forbid it from accessing the network. The second doe…

Good point. Many build systems also want to be a package manager, but the two are and should be separate. If you have a simple problem it makes things easy to combine them into one. However they need to be separate anyway, both for security and also to make other weird situations easier.

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

#147

Post by insanitybit »

quotemstr wrote: post #120
insanitybit wrote: post #111

Earlier quoted context omitted.

You can't simultaneously say that we've had the tech for years and also say that it doesn't work. We have not had the tech for years. x-plat sandboxing is extremely difficult, especially in a way that's performant. Sandboxing almost always involves having a dedicated, privileged service, due to how operating systems have designed things. It requires platform specific code. This is a technical problem and a social pro…

The technology works fine if you use it in a disciplined way. The problem is that people don't! You're necessarily going to break programs if you put them in restricted environments. That's not the same as the restriction technology not working properly. > Sandboxing almost always involves having a dedicated, privileged service, due to how operating systems have designed things. Or just invoking bwrap. Or sandbox-exe…

> The technology works fine if you use it in a disciplined way.

Then obviously we have to discuss the implementation!

> Or just invoking bwrap. Or sandbox-execute. There's no performance overhead. Complexity is minimal. Just read current Codex source code. It's not so bad. People have been making these sandbox tools for AI agents for years. Just need to apply sandboxing to all domains.

Tools like bwrap literally could not have existed until very recently without also requiring suid/ privileges, and even today unprivileged user namespaces are not universally enabled. This is why the implementation matters. No, unprivileged sandboxing has not been around for years, especially not x-plat. bwrap is a perfect example of what I'm talking about, great reference - it either requires root or it requires unprivileged user namespaces and it's not x-plat. Great.

> You want some kind of silver bullet that makes code "safe" without anyone having to change anything? To prompt for nothing? To use no IPC portal? That's not happening.

I have no idea why you think I've said this, I'm pointing out that the implementation and technology matters deeply.

> The people saying we need a new language or something are half right. We don't need a new language. A pure library solution is fine! But people do need to do work to make an ecosystem based on capabilities and least privilege to work. And we need to tell people who refuse to do this work to go to hell.

Again, you can't say "this technology has existed for years! You can do it in a library!" and then say "but they don't!". You misunderstand the complexity and assert that it's merely a matter of will. It is both.

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

#148

Post by quotemstr »

insanitybit wrote: post #147
quotemstr wrote: post #120

Earlier quoted context omitted.

The technology works fine if you use it in a disciplined way. The problem is that people don't! You're necessarily going to break programs if you put them in restricted environments. That's not the same as the restriction technology not working properly. > Sandboxing almost always involves having a dedicated, privileged service, due to how operating systems have designed things. Or just invoking bwrap. Or sandbox-exe…

> The technology works fine if you use it in a disciplined way. Then obviously we have to discuss the implementation! > Or just invoking bwrap. Or sandbox-execute. There's no performance overhead. Complexity is minimal. Just read current Codex source code. It's not so bad. People have been making these sandbox tools for AI agents for years. Just need to apply sandboxing to all domains. Tools like bwrap literally coul…

Browsers have been sandboxing their tabs since 2008. Don't sit there and tell me that bwrap, sandboxing, whatever is some kind of recent innovation with uneven distro support.

And yes, bwrap needs root or namespaces. So what? So does sudo. Setuid binaries are as old as time.

You know what's also been around and doesn't require root? Landlock. Have you heard of it? Has anyone? There's a huge PR and visibility gap in this space. We don't have to invent some new thing. We have to get people to learn about what we already have and use it.

"Oh, the technology works, but it need setup! Oh, my distro doesn't enable it! Oh, it doesn't work out of the box with my code!"

This is a social problem. It's not a technology problem. It's people not wanting to do the work, not understanding what already exists, dismissing solutions based on non-problems (like bwrap needing privileges on some systems), and in general adopting an attitude of "no", not a can-do problem solving stance.

And we're supposed to solve this problem with let another precious little effects language or another fucking MicroVM environment? FFS.

We need unprivileged sandboxing!"

"Use bwrap"

"Nooo, that needs setuid root or file caps!!!1!1"

"So the problem is that bwrap is part of the TCB?"

"Yes. We need sandboxing that relies only on unprivileged code like the Linux kernel"

... the fuck?

You can't solve a social problem with technology.

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

#149

Post by kevincox »

vaylian wrote: post #115
tancop wrote: post #75

We need effect based languages now. It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles. If anyone from epic is reading this please give us a timeline for open sorucing the Verse compiler. In the mean time I think it's possible to hack Cargo and run all build scripts in a microVM. The blast radius will be limited to malicious code in the…

> It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles. It's not the only way. You can sandbox processes. I think sandboxing is the much more reasonable approach, because in the end of the day, there are still closed-source software products where you can't demand that the manufacturers use certain language safety features.

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 silver bullet.

Capability security in-language would make a huge difference, because the more granular you "sandbox" the less likely it is that the compromised component has the access it wants. For example if the HTTP client library is compromised maybe it can't access the filesystem so can't steal your cookies. Or maybe like in this case no permissions were needed at all and despite the process having enough capabilities for malware this malware can at worst return bad values and try to chain this to an exploit which is far more difficult than just running it itself.

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

#150

Post by bel8 »

kibwen wrote: post #106
abbadadda wrote: post #68

Are there any plans to more seriously develop the standard library in Rust? Or is the plan to remain in this status quo where users of Rust import nonsense and the dependency tree explodes (or users are forced to invent their own wheel?). Are there any comparisons between the state of the stdlib in C++ vs. Rust? I’d think that would serve as an excellent jumping off point to start chipping away.

The idea that Rust has a small standard library is a weird meme. Rust has an enormous standard library. Look at any Rust release and you'll see dozens of new library APIs added, and consider that Rust has about nine releases a year, meaning that Rust adds over a hundred APIs per year, and has consistently for the past ten years. Rust frequently adds things that obviate popular crates, most recently the cfg_if crate w…

It still lacks basic functionality like a JSON parser, regex, directory walker, rnd generator and cli arg parsing.

I won't mention lack of date/time lib because that's complex and changes often.

That's why projects end up with 100s of crates, sometimes 1000s.

This might not be a well received fact in Rust community, but it's a fact nonetheless.

Post reply on HN