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

411–420 of 529 posts

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

#411

Post by hbcdbff »

acje wrote: post #313
cube00 wrote: post #114

GitHub really needs something finer-grain then just pretending the repo never existed during these incidents. [1] The bad package version has also just disappeared from crates.io [2] with no indication its been yanked. There's no security advisory there either [3] "No advisories found for this crate." I feel crates.io was unprepared for a security incident like this since they're managing the response [4] [1]: https:…

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

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

#412

Post by waterTanuki »

> append-only-vec

> This is a pretty simple type, which is a vector that you can push into, but cannot modify the elements of. The data structure never moves an element once allocated, so you can push to the vec even while holding references to elements that have already been pushed.

This is the left-pad of rust. Reconsider your life decisions if you need to pull in an external dependency replicable with 30 lines of code:

    use std::vec::Vec;

    #[derive(Debug)]
    pub struct AppendOnlyVec {
        inner: Vec,
    }

    impl AppendOnlyVec {
        pub fn new() -> Self {
            Self {
                inner: vec![],
            }
        }

        pub fn push(&mut self, element: T) {
            self.inner.push(element);
        }

        pub fn clear(&mut self) {
            self.inner.clear();
        }
    }

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

#413

Post by pjmlp »

VorpalWay wrote: post #353
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.

Which is how you get the mess that is the standard library of C++. Where regex is an unusably slow joke and everyone uses third party libraries for that instead. And tons of parts of the standard library (and language) being cordoned off as "legacy, don't use for new development". Of course figuring out what you shouldn't use in C++ can be hard too. It isn't well documented (or universally agreed upon), and it takes…

Regex drama is overblown, it is quite usable for most business purposes.

Sure, it would be great if the volunteers that contribute to C++ compilers, would improve regex instead of adding the gazillion of features that each ISO C++ standard requires, mostly on their free time, because devs can't be bother to pay for compilers.

Additionally the companies that actually sponsor those compilers also have bigger priorities than improving regex implementation.

Finally if you want to stick regex into a micro-benchmarks context, there are plenty of options out there, as you point out.

The Rust way, like you can have any async runtime, as long as it is Tokio?

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

#414

Post by pjmlp »

kelnos wrote: post #406
pjmlp wrote: post #328

Earlier quoted context omitted.

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.

It's interesting that you include Java in there, as I've worked on some pretty bog-standard Java code bases where the dependency tree didn't look all that different from a cargo project's.

It starts by those that reach out for Log4J, when java.util.logging.Logger already does the job.

Guava for whatever cool reason, and so on.

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

#415

Post by pjmlp »

VorpalWay wrote: post #354
kergonath wrote: post #239

Earlier quoted context omitted.

> We also have the classic example of PHP with numerous not safe stdlib ways to use mysql. I think it goes without saying that emulating PHP is rarely a good decision.

Don't forget C++ where large parts of the standard library are unusable (regex is slow and unfixable) or soft deprecated (dont use iostreams for formatting, use std::format, etc). No, I prefer what rust is doing. It suits a system programming language. Which is what Rust is.

Regex does the job for most business software, iostreams is alright, using them since 1993, std::format is cool provided one has control over their compiler version,...

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

#416

Post by sarahsoup »

rvz wrote: post #18
tsimionescu wrote: post #12

> arrayref is a small crate of four macros. Why do so many languages fall into this horrible practice?

The languages that have a poor standard library support have this issue and other languages encourage you to import tons of libraries to fix the problem. This is why Javascript and Typescript suffer from this the most and has little to nothing to do with "popularity" and likely 9/10 of these npm packages import an external library. Golang on the other-hand is just as popular and has a stronger standard library which…

C has a piss poor standard library and doesn't have this problem.

Make dependencies annoying to use and it forces people to be more disciplined about them and if you do insist on a package manager you should not support transitive dependencies at all, packages should be self contained.

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

#417

Post by looperhacks »

mike_hearn wrote: post #213
swiftcoder wrote: post #93

Earlier quoted context omitted.

build.rs by design can run absolutely anything. There tons of build.rs scripts that invoke a whole-ass C compiler toolchain to build and link C dependencies... It isn't so much a question of sandboxing build.rs, as fundamentally changing the way that foreign dependencies are integrated into the rust toolchain (i.e. moving from a rust-centric system like Cargo to something more general like buck2)

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.

[dead]

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

#418

Post by LtWorf »

dwroberts wrote: post #151
hbbio wrote: post #79

Rust suffers from the same faults as the JS ecosystem. Any significant crate imports hundreds if not thousands of dependencies. The probability that one of the authors gets targeted by AI-assisted attacks is just too high. Also most of these dependencies provide a breadth of features that the end package does probably not need.

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?

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

#419

Post by hnlmorg »

fidotron wrote: post #201
hnlmorg wrote: post #190

Earlier quoted context omitted.

Two problems with this: 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. 2. Even if there were, if you’re compiling untrusted code then why would you trust the built output? If you’re building the create then I’d argue that any preventative steps afterwards is akin to closing the barn door after the horse has already bolted.

> 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’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).

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

#420

Post by hnlmorg »

jonahx wrote: post #210
hnlmorg wrote: post #190

Earlier quoted context omitted.

Two problems with this: 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. 2. Even if there were, if you’re compiling untrusted code then why would you trust the built output? If you’re building the create then I’d argue that any preventative steps afterwards is akin to closing the barn door after the horse has already bolted.

> There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. I said OS level. It's something I should easily be able to do via the OS capabilities that would work for rust, npm, etc. I would use it not only for rust builds but for nearly every app on my computer.

That’s already easy to do. In fact most CI/CD pipelines already work this way. The problem is you still have a compromised executable at the end of the pipeline. So you haven’t actually solved much.
Post reply on HN