5 ms·

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 cod

by tharne 11mo ago

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.

MattPalmer1086 11mo ago
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.
- immibis 11mo ago
  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.
  - MattPalmer1086 11mo ago
    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).
- jacquesm 11mo ago
  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.
  - acdha 11mo ago
    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.
    - jacquesm 11mo ago
      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.
bluGill 11mo ago
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.
- semi-extrinsic 11mo ago
  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.
  - bluGill 11mo ago
    Anyone writing C quickly learns to find third party libraries that do lots of things for them.
  - antonvs 11mo ago
    > 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 https://github.com/fffaraz/awesome-cpp
rpcope1 11mo ago
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.
xmodem 11mo ago
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.
- tharne 11mo ago
  > "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.

by tharne 11mo ago

MattPalmer1086 11mo ago

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.

immibis 11mo ago
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.
- MattPalmer1086 11mo ago
  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).
jacquesm 11mo ago
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.
- acdha 11mo ago
  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.
  - jacquesm 11mo ago
    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.

bluGill 11mo ago

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.

semi-extrinsic 11mo ago
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.
- bluGill 11mo ago
  Anyone writing C quickly learns to find third party libraries that do lots of things for them.
- antonvs 11mo ago
  > 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 https://github.com/fffaraz/awesome-cpp

rpcope1 11mo ago

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.

xmodem 11mo ago

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.

tharne 11mo ago
> "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.