2 ms·

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 updat

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 1y 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 1y ago
  Anyone writing C quickly learns to find third party libraries that do lots of things for them.
- antonvs 1y 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
- lmm 1y ago
  > 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.
ploxiln 1y ago
> 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.
- GuuD 1y ago
  Zero that we know of
  - 0cf8612b2e1e 1y ago
    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.
- walletdrainer 1y ago
  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.

semi-extrinsic 1y 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 1y ago
Anyone writing C quickly learns to find third party libraries that do lots of things for them.
antonvs 1y 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
lmm 1y ago
> 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.

ploxiln 1y ago

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

GuuD 1y ago
Zero that we know of
- 0cf8612b2e1e 1y ago
  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.
walletdrainer 1y ago
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.