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

281–290 of 529 posts

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

#281

Post by cogman10 »

eminence32 wrote: post #203
cube00 wrote: post #180

Earlier quoted context omitted.

> They're definitely not unprepared for an incident like this. We shouldn't need to resort to pasting `find` commands [1] into the shell from blog posts to tell if we're compromised. `cargo audit` should be reporting if these packages have been downloaded. The "What you need to do" section of the blog should be run `cargo audit` > Not having an advisory INSTANTLY available isn't a sign of a decaying org. Chill. The G…

> We shouldn't need to resort to pasting `find` commands [1] into the shell from blog posts to tell if we're compromised. I know you recommended `cargo audit`, but that is not nearly as universally installed as `find`. And as far as I know, cargo-audit has to be run within a project directory? Can it be run outside of the context of a project and scan the cargo registry cache? I personally appreciated having the `fin…

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.

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

#282

Post by amluto »

kibwen wrote: post #271
amluto wrote: post #186

Earlier quoted context omitted.

As an easy start, how about letting build scripts read /usr, read and write a temporary build directory, have some /tmp scratch space, and be allowed to write its final output artifact. No network and otherwise isolated from the rest of the system. I would argue that, if a build script doesn’t work in the setting, then it doesn’t deserve to be installable by a default cargo command.

Cargo is a cross-platform tool, so when it ships a sandboxing solution it will need to be a cross-platform solution, and because this is a security feature it needs to be bulletproof, so no half-measures like Docker. Something like a WASM runtime might fit the bill, though that will be much easier to get working for typical proc macros than for typical build scripts. If you only care about Unix, then you can do this…

> Cargo is a cross-platform tool, so when it ships a sandboxing solution it will need to be a cross-platform solution

This seems like an excuse, not an actual objection.

Linux can do seccomp or Landlock or gVisor or a combination. Seccomp and gVisor need no privileges. Windows has its internal weird mechanisms. Mac has sandbox-exec.

Cargo could easily pick an appropriate sandbox for each major platform and ship it by default.

> If you only care about Unix, then you can do this yourself today by building code in your sandbox of choice.

This is ridiculous. The sandbox should not have network access, but cargo needs network access to download the package in the first place.

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

#283

Post by afdbcreid »

yoyohello13 wrote: post #85
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…

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.

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

#284

Post by cogman10 »

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.

I agree. Java has the same ability to quickly add deps, and in some case they can be sprawling, but it's still perfectly possible to develop complex apps without a lot of deps coming in.

Culture has a lot to do with it.

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

#285

Post by fwlr »

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 they exit.
So the malicious build script has a helpful comment (???), written in a familiar “terse nouns verbing” style (!!!).

Would it be gauche to speculate? Maybe some script kiddy sweet-talked Fable into dropping its safeguards, or maybe Anthropic is doing a training run for Fable 5.1 and the air-gaps aren’t gapping.

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

#286

Post by cogman10 »

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?

That or potentially fast tracking merging popular libraries into the standard library. Or at least concepts from popular libraries. Basically all the "most downloaded" crates on the Crates.io front page should be candidates for merging into the standard library.

https://crates.io/

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

#287

Post by cesarb »

kibwen wrote: post #166
jfklgkdkdnn wrote: post #67

Earlier quoted context omitted.

minimum-release-age

Cargo has been working on min-publish-age, and the PR to stabilize the feature is in its final comment period and currently expected to land in Rust 1.100: https://github.com/rust-lang/cargo/pull/17335#issuecomment-5...

> rust-rfcbot commented 2 days ago: This is now entering its final comment period

I wonder if this is not in part the same situation as we arguably had with the xz compromise: some imminent change would have made the attack harder (in xz's case, IIRC a change to systemd to dlopen the compression library instead of directly depending on it), and the attacker rushed before the opportunity window closed.

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

#288

Post by overfeed »

__david__ wrote: post #256
segphault wrote: post #195

Earlier quoted context omitted.

This is spot on. I am extremely uncomfortable with the large number of transitive dependencies that end up in pretty much any non-trivial rust application. No amount of memory safety will save us if a tiny, ubiquitous library that nobody scrutinizes because it’s nested eight layers down the dependency graph gets compromised. I think Go apps tend to have better dependency hygiene because the language has a better stan…

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…

> Certainly having a larger stdlib helps Go projects keep their deps down, but I don't think it's the real reason

I disagree: having a big stdlib that encompasses a huge chunk of common functionality (logging, a plethora of network server/client protocols, etc) means that for basic needs, the question of 3rd party libs never arise, whereas for other language, the question is not if you need a dep, but which one. Making gorilla easier to find won't undo the cultural reluctance of adding a 3rd party dep when using the (very pragmatic, IMO) stdlib server is adequate to the task.

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

#289

Post by cosmic_cheese »

TZubiri wrote: post #260
cosmic_cheese wrote: post #247

Earlier quoted context omitted.

I don't like the "bring your own" approach because unless one happens to be an absolute tour de force 10x engineer unstoppable god of a programmer (which most of us, myself included, are not), whatever you build is never going to be as well-rounded, fleshed out, and complete as something built by a larger organization, especially when it comes to UI libraries (which are monstrous projects if done right, e.g. meeting…

I agree that building your own is hard and something that can be done by exceptional engineers, but software is famously a winner-take-all industry, even if the optimal strategy for lower percentile programmers and median programmers to import generic modules, as long as building your own results in the best product (which it does, whether importing frontend or backend modules, if you hand code something, it's going…

> Also the challenge of building a generic module is much larger than building your own. A generic module needs to have flexibility for many different options and integrations, when you build your own you build just what you need and tightly integrate it with the product

True but I believe overestimated. Usually rather than building what's needed, what gets built is what is thought to be needed (often a substantially smaller subset), and then over time you end up building a markedly poor version of a generic module.

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

#290

Post by conradludgate »

cogman10 wrote: post #281
eminence32 wrote: post #203

Earlier quoted context omitted.

> We shouldn't need to resort to pasting `find` commands [1] into the shell from blog posts to tell if we're compromised. I know you recommended `cargo audit`, but that is not nearly as universally installed as `find`. And as far as I know, cargo-audit has to be run within a project directory? Can it be run outside of the context of a project and scan the cargo registry cache? I personally appreciated having the `fin…

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.
Post reply on HN