Hacker News Reader

Comment by tharne | Hacker News Reader

This is something I've never totally understood when it comes to Rust's much loved memory safety vs. C's lack of memory safety. When it comes to replacing C code with Rust, aren't we just trading memory risk for supply chain risk?

Maybe one is more important than the other, I don't know. All the languages I use for work or hobbies are garbage collected and I'm not a security professional. But it does seem like the typical Rust program with it's massive number of "cargo adds" is an enormous attack surface.

View on HN

The supply chain attack always existed. C because it didn't have a package manager made it slightly harder in that a dependency wouldn't be automatically updated, while Rust can do that. However this is very slight - in linux many people use libraries from a package manager which gets updated when there is a new release - it wouldn't be hard to get a bad update into a package (xz did that).

If you have packages that don't come from a package manager - windows install, phone installs, snap, docker, flatpack, and likely more you have a different risk - a library may not have been updated and so you are vulnerable to a known flaw.

There is no good/easy answer to supply chain risk. It is slightly different on Rust because you can take the latest if you want (but there is plenty of ability to stay with an older release if you want), but this it doesn't move the needle on overall risk.

Au contraire, the Rust (or other "modern" lang) dependencies come in addition to the OS dependencies. The C (or other "old" lang) programs typically have very few dependencies apart from the OS, with absolutely glacial release cycles. And unless you're on Arch or similar, the OS package manager updates are primarily just minor version bumps.

It seems pretty indisputable that "modern" langs substantially increase your supply chain attack surface. Of course some (like JS) are worse than others.

As a result, whether the net security benefit of using Rust vs C is positive or negative depends heavily on the program in question. There is a huge difference between e.g. Firefox and Wireguard in this respect.

Anyone writing C quickly learns to find third party libraries that do lots of things for them.

> The C (or other "old" lang) programs typically have very few dependencies

Say what now? Have you ever worked on a project that uses C?

We were using 3rd party dependencies in C in the 1980s.

Here's a more current list for C and C++: https://github.com/fffaraz/awesome-cpp

> The C (or other "old" lang) programs typically have very few dependencies apart from the OS, with absolutely glacial release cycles.

Very few by number, but that's more an artifact of C's poor package management than a true reflection of how much third-party code you're actually pulling in. Something like APR is the equivalent of hundreds of Rust packages, and comes with a similar security risk. Sure, maybe there's someone who signs off on each release, but do you think they personally know and validate each of the dozen or more mostly-independent projects that actually make up their library? No, they delegate to separate maintainers - that information just isn't surfaced in the package management system.

> it wouldn't be hard to get a bad update into a package (xz did that)

I'd actually call that quite difficult. In the case of xz it was a quite high-effort "long con" the likes of which we've never seen before, and it didn't quite succeed in the end (it was caught before rolling out to stable distros and did not successfully exploit any target). One huge close call, but so far zero successes, over almost 30 years now.

But typo-squatting and hijacked packages in NPM and PyPI, we've seen that 100s of times, many times successfully attacking developers at important software companies or just siphoning cryptocurrency.

Zero that we know of

Certainly seems absurd to think that xz was the only target Jia Tan had been pursuing for years. Surely there were parallels initiatives to exploit other projects in the security chain.

You could just hack someone responsible for the package you want to target or one of its dependencies, and skip the long con entirely.

Given the amount of potential targets, it would probably be trivial to get yourself into a position to cause devastating impact.

No-one's forcing you to use crates published on the crates.io registry - cargo is perfectly happy to pull dependencies from a different public or private registry, elsewhere in the same repo, somewhere else on the filesystem, pinned to a git hash, or I think some other ways.

"We shouldn't use the thing that has memory safety built in because it also has a thriving ecosystem of open source dependencies available" is a very weird argument.

> "We shouldn't use the thing that has memory safety built in because it also has a thriving ecosystem of open source dependencies available" is a very weird argument.

I don't see anyone anywhere in this thread saying that we shouldn't use rust, or C for that matter.

It's rare not to use open source libraries no matter the language. Maybe C code tends to use fewer, I don't know.

This doesn't prove anything of course, but the only High severity vulnerability I had in production this year was a C library. And the vulnerability was a buffer overflow caused by lack of memory safety.

So I don't think it's a simple trade off of one sort of vuln for another. Memory safety is extremely important for security. Supply chain attacks also - but using C won't defend you from those necessarily.

There's no canonical package manager or packaging convention for C and C++ libraries, since they predate that sort of thing. As a result, there's a lot more friction to using dependencies and people tend to use less of them. Common OS libraries are fair game, and there are some large widely used libraries like boost, but it's extremely unusual for a C or C++ project to pull in 20+ very small libraries. A chunk of functionality has to be quite big and useful before it overcomes the friction of making it a library.

Right, makes sense. Although I guess people directly download third party source and just include it too (rather than reference it in a known package you can more easily track).

It is extremely rare for a C build environment to start downloading a massive number of unaudited dependencies from a poorly organized pile of endless layers of repositories. What you might have is a couple of dependencies and then you build the rest yourself. To have 800 unknown co-authors on your 'hello world' app would not happen in C.

There are of course still other vectors for supply chain attacks. The toolchain itself, for instance. But then you fairly quickly get into 'trusting trust' level issues (which are very real!) and you will want an OS that has been built with known clean tools as well.

The flip side is that the median C program has more first-party security bugs and likely has third-party bugs included as copies which will be harder to detect and replace. I remember years ago finding that a developer had copied something like a DES implementation but modified it so you had to figure out what they’d customized as part of replacing it.

So far I have not found this to be the case. Usually stuff is fairly high quality and works for the use cases that I throw at it. Your example sounds like very risky behavior. That stuff is super hard to get exactly right.

That same problem bites in other ways too. There was a discussion in I think the Debian mailing lists around Rust applications potentially being slower to patch because everything gets linked in statically (so you can't just patch libssl and pull a new so). I imagine if you have one compromised dependency, it's now going to mean pulling a new version for each and every single package that may have incorporated it, which feels like it's going realistically to mean AAA game assets size updates weekly.

Reply on news.ycombinator.com