Hacker News Reader

Comment by nindalf | Hacker News Reader

Everything looks obvious in hindsight doesn’t it? Several of the organisations you’ve mentioned have funded projects to rewrite critical internet infrastructure in a memory safe language - HTTP client, HTTP reverse proxy, DNS resolver, NTP server, TLS library, AV1 decoder, a replacement for sudo, among other projects (https://memorysafety.org). More can always be done, and it can always be done faster than it’s being done.

Fwiw, it’s possible to use zstd instead of xz, which was created at and actively maintained at Facebook.

So if you were expecting Big Tech to identify this class of problem and do something about it, it seems like they are. But if you expected them to eliminate every single possible instance of such an issue, that’s a bit much isn’t it?

View on HN

Would a 'memory safe' language really have stopped any of this? From what I've briefly read, this incident the whole attack process (PR, fake test data, social engineering) from start to finish by a state-actor (most likely), could have been in any language.

You are right, but C/C++ was vulnerable to this particular MO because of its complicated build process.

I would say today there is no real need for autoconf anymore in C / C++ and the build process could be fairly easy.

There are million ways to hide exploits even in "safe" languages. If you have a bad actor that can spend couple years prepping how to hide an exploit, then it doesn't really matter which programming language is used.

Build system is complex because of legacy and need to support millions of different platforms and distros.

Different platforms and distros still share a handful of common environments, while autoconf was invented back when there were hundreds of different environments to care about. Xz doesn't depend that much on the platform and could have ditched autoconf at least in the theory. But such switch is annoying in the world of C/C++.

I'd say there are fewer ways to hide exploits like this. Rust doesn't use configure scripts. And it has a built in testing mechanism - so there's no need for makefiles to run scripts. Any build scripts as complicated as configure in a rust project would be a much bigger red flag. And it would be rare and weird to see GNU_IFUNC in use in a rust project too.

Sure; you can hide nasty code in rust. But I think it would have been harder. Not because rust is memory safe. But because rust is decades newer, and it doesn't inherit all of the quirks in C, in its build system and obscure mechanisms for dynamic linking.

It's easy to hide things in the Python build process as well. Things like using `getattr` instead of . (dot) etc

> could have been in any language

Bingo. This was a highly motivated, targeted, and well planned compromise of the supply chain itself. And funnily enough, using a memory-safe language could have actually made it less likely for this to be detected.

There were symptoms showing up prior to the discovery, most prominently Valgrind errors in otherwise unrelated project builds. (ref: https://bugzilla.redhat.com/show_bug.cgi?id=2267598)

The equivalents in memory safe languages raise more eyebrows. Segfault developing on a shared C codebase and it's a day ending with y. Segfault in a language that's meant to not let that happen? Or conversely if a patch turns up that's explicitly doing lots of unsafe things? That gets more scrutiny.

People like to harp on software written in C, and often for very good reasons. A vocal minority of those then whip out their calling card, "should have used Rust!"

As a result, there is a sentiment in the peanut gallery that "memory safe language == Rust".

You are correct in that a segfault in a project written in memory safe language gets more scrutiny. But imagine for a moment what would have happened if the compiler guaranteed that those Valgrind-caught memory access violations could not have occurred in the first place?

We got lucky, and the developers who wrote the actual backdoor were sloppy. They were aiming for sneakiness and evasion first, memory correctness would have likely been an afterthought. The next group tasked with a similar approach will know better.

Yes, they used a memory corruption bug to run the payload.

And if the code submitted used Rust's 'unsafe'?

Then it would be a massive shining "review me harder daddy" beacon

You're imagining things, there is no memory corruption mechanism. The payload is delivered into the process address space by dynamic linking through a shared dependency and hijacks a function via GNU_IFUNC.

Well, Rust doesn’t support dynamic linking. So this particular attack wouldn’t be possible with Rust in March 2024.

But it’s a moot point because there are undoubtedly other mechanisms a malicious maintainer could use to inject a vulnerability. Just not this exact one.

Yes, But it would at least be harder. C has so many weird quirks and edge cases - including decades of legacy mechanisms (like IFUNC) that almost nobody today understands.

The underhanded C contest would be a lot less entertaining in rust. Thats a good thing.

It wouldn't solve the underlying problem permanently. But I don't think there's any slam-dunk solution here. I'll take any small wins where we can get them.

There was an Underhanded Rust contest many years ago https://news.ycombinator.com/item?id=15352253

As far as I can tell, Rust _does_ support dynamic linking. You can both compile rust code to .so and link against existing shared objects. What are you talking about?

>The compiler supports various methods to link crates together both statically and dynamically. This section will explore the various methods to link crates together, and more information about native libraries can be found in the FFI section of the book.

https://doc.rust-lang.org/reference/linkage.html

> What are you talking about?

I’m talking about what happens in practice, which is shipping static binaries that contain all of their dependencies, except for libc.

Rust does support dynamic linking, it's just not that useful because of the unstable ABI. You can dynamically link against C code, or Rust code presenting a C ABI, without issue, and you can dynamically link against Rust code if you accept the inherent limitations at the moment

Well Valgrind originally went off on it and oss-fuzz presumably would have caught it since here's a PR from the attacker asking for it to be disabled: https://github.com/google/oss-fuzz/pull/10667

capability safety inhibits supply chain attacks. memory safety is a prerequisite, but it is not sufficient

Right now they’re worried that somewhere in those 700 commits added by the malicious maintainer there may be some subtle memory safety bug. So great is the difficulty of finding these bugs that they’re planning to discard all work since the commiter became involved, including work by others.

Introducing such hidden bugs that are basically impossible to find is much harder in a memory safe, statically linked language.

Reply on news.ycombinator.com