5 ms·

Wouldn't a supply chain attack like this be much worse with Rust and Cargo because of the fact it's not just a single dynamic library that needs to be reinstall

Wouldn't a supply chain attack like this be much worse with Rust and Cargo because of the fact it's not just a single dynamic library that needs to be reinstalled system-wise, but, instead, every binary would require a new release?

gpm 3y ago
It would mean rebuilding more packages. I don't think that's meaningfully "much worse", package mangers are perfectly capable of rebuilding the world and the end-user fix is the same "pacman -Syu"/"apt-get update && apt-get upgrade"/... On the flip side the elegant/readable build system means that the place this exploit was hidden wouldn't exist. Though I wouldn't confidently say that 'no hiding places exist' (especially with the parts of the ecosystem that wrap dependencies in other languages).
- ok123456 3y ago
  It's much worse because it requires repackaging every affected system package instead of a single library. Knowing which packages are affected is difficult because that information isn't exposed to the larger system package manager. After all, it's all managed by the build system.
  - packetlost 3y ago
    In the era of modern CI and build infrastructure, I don't really think that's materially an issue.
    - ok123456 3y ago
      Those CI and build infrastructures rely on the Debian and RedHat being able to build system packages. How would an automated CI or build infrastructure stop this attack? It was stopped because the competent package maintainer noticed a performance regression. In this case, this imagined build system would have to track every rust library used in every package to know which packages to perform an emergency release for.
      - packetlost 3y ago
        I... don't see your point. Tracking the dependencies a static binary is built with is already a feature for build systems, just maybe not the ones Debian and RH are using now, but I imagine they would if they were shipping static binaries. Rust isn't really the point here, it's the age old static vs dynamic linking argument. Rust (or rather, Cargo) already tracks which version of a dependency a library depends on (or a pattern to resolve one), but it's besides the point.
        ok123456 3y ago
        Rust is the issue here because it doesn't give you much of an option. And that option is the wrong one if you need to do an emergency upgrade of a particular library system-wide.
        packetlost 3y ago
        It's really not, it's not hard to do a reverse search of [broken lib] <= depends on <= [rust application] and then rebuild everything that matches. You might have to rebuild more, but that's not really hard with modern build infrastructure. Not to mention if you have a Rust application that depends on C libraries, it already dynamically links on most platforms. You only need to rebuild if a Rust crate needs to be updated.
      - steveklabnik 3y ago
        > imagined Cargo already has this information for every project it builds. That other systems do not is their issue, but it’s not a theoretical design.
        ok123456 3y ago
        So, I know that librustxz has been compromised. I'm Debian. I must dive into each rust binary I distribute as part of my system and inspect their Cargo.toml files. Then what? Do I fork each one, bump the version, hope it doesn't break everything, and then push an emergency release!??!
JanisErdmanis 3y ago
This seems to be an orthogonal issue. Rust could build the same dynamic library with cargo which could then be distributed. The diference is that there would be a single way to build things.
- ok123456 3y ago
  Most Rust libraries are not dynamically linked; instead, versions are pinned and included statically during the build process. This is touted as a feature. Only a few projects are built as system-wide libraries that expose a C-compatible abi interface; rsvg comes to mind.
  - timschmidt 3y ago
    It's not touted as a feature by any Rust developers I know of. The Rust ABI is merely still stabilizing. See: https://github.com/rust-lang/rust/pull/105586 https://github.com/rust-lang/rust/pull/105586
YetAnotherNick 3y ago
I am not completely sure about this exploit, but seems like a binary needed to be modified for the exploit to work[1] which was later picked up by build system. https://github.com/tukaani-project/xz/commit/6e636819e8f070330d835fce46289a3ff72a7b89 https://github.com/tukaani-project/xz/commit/6e636819e8f0703...
- ok123456 3y ago
  The binary was an xz test file that contained a script that patched the c-code.

gpm 3y ago

It would mean rebuilding more packages. I don't think that's meaningfully "much worse", package mangers are perfectly capable of rebuilding the world and the end-user fix is the same "pacman -Syu"/"apt-get update && apt-get upgrade"/... On the flip side the elegant/readable build system means that the place this exploit was hidden wouldn't exist. Though I wouldn't confidently say that 'no hiding places exist' (especially with the parts of the ecosystem that wrap dependencies in other languages).

ok123456 3y ago
It's much worse because it requires repackaging every affected system package instead of a single library. Knowing which packages are affected is difficult because that information isn't exposed to the larger system package manager. After all, it's all managed by the build system.
- packetlost 3y ago
  In the era of modern CI and build infrastructure, I don't really think that's materially an issue.
  - ok123456 3y ago
    Those CI and build infrastructures rely on the Debian and RedHat being able to build system packages. How would an automated CI or build infrastructure stop this attack? It was stopped because the competent package maintainer noticed a performance regression. In this case, this imagined build system would have to track every rust library used in every package to know which packages to perform an emergency release for.
    - packetlost 3y ago
      I... don't see your point. Tracking the dependencies a static binary is built with is already a feature for build systems, just maybe not the ones Debian and RH are using now, but I imagine they would if they were shipping static binaries. Rust isn't really the point here, it's the age old static vs dynamic linking argument. Rust (or rather, Cargo) already tracks which version of a dependency a library depends on (or a pattern to resolve one), but it's besides the point.
      - ok123456 3y ago
        Rust is the issue here because it doesn't give you much of an option. And that option is the wrong one if you need to do an emergency upgrade of a particular library system-wide.
        packetlost 3y ago
        It's really not, it's not hard to do a reverse search of [broken lib] <= depends on <= [rust application] and then rebuild everything that matches. You might have to rebuild more, but that's not really hard with modern build infrastructure. Not to mention if you have a Rust application that depends on C libraries, it already dynamically links on most platforms. You only need to rebuild if a Rust crate needs to be updated.
    - steveklabnik 3y ago
      > imagined Cargo already has this information for every project it builds. That other systems do not is their issue, but it’s not a theoretical design.
      - ok123456 3y ago
        So, I know that librustxz has been compromised. I'm Debian. I must dive into each rust binary I distribute as part of my system and inspect their Cargo.toml files. Then what? Do I fork each one, bump the version, hope it doesn't break everything, and then push an emergency release!??!

JanisErdmanis 3y ago

This seems to be an orthogonal issue. Rust could build the same dynamic library with cargo which could then be distributed. The diference is that there would be a single way to build things.

ok123456 3y ago
Most Rust libraries are not dynamically linked; instead, versions are pinned and included statically during the build process. This is touted as a feature. Only a few projects are built as system-wide libraries that expose a C-compatible abi interface; rsvg comes to mind.
- timschmidt 3y ago
  It's not touted as a feature by any Rust developers I know of. The Rust ABI is merely still stabilizing. See: https://github.com/rust-lang/rust/pull/105586 https://github.com/rust-lang/rust/pull/105586

YetAnotherNick 3y ago

I am not completely sure about this exploit, but seems like a binary needed to be modified for the exploit to work[1] which was later picked up by build system. https://github.com/tukaani-project/xz/commit/6e636819e8f070330d835fce46289a3ff72a7b89 https://github.com/tukaani-project/xz/commit/6e636819e8f0703...

ok123456 3y ago
The binary was an xz test file that contained a script that patched the c-code.