7 ms·

Some months ago after recoiling in horror from a vulnerability in rust I arrived at the grim realization that the "supply chain attack" problem is intractable i

Some months ago after recoiling in horror from a vulnerability in rust I arrived at the grim realization that the "supply chain attack" problem is intractable in impure languages. When a transitive dependency can do anything it will inevitably do something. I don't expect to convert everyone (or anyone) to object capabilities and purity, but I do hope the experiences of the past year have put the fear of God into developers. We should aspire to build systems where a suddenly malicious or busted dependency can't knock over the whole tower.

TAForObvReasons 4y ago
the current fragility of the "software supply chain" stems from package managers and their perverse economic incentives, and this is just as true for "pure languages". Vendoring and auditing dependencies greatly reduces the attack surface area.
- bhickey 4y ago
  Can you elaborate on the incentives of package managers? The problem I see with Rust is that it's just really easy to add dependebcies in a way that is difficult in C++. I don't follow your point about purity. A dependency in a side-effect free language can't suddenly open a socket or access the file system. The attack surface is much smaller.
  - busterarm 4y ago
    > A dependency in a side-effect free language can't suddenly open a socket or access the file system. A dependency can exploit your system deliberately, not just with side effects. If you're not strictly pinning all of your dependency versions, one malicious update that makes it to the package manager can ruin your whole world. Our package managers operate entirely on trust. Nobody is guaranteed to be checking to make sure some random package's maintainer isn't submitting malicious updates. As a community we're all lazy and basically hope that somebody else is invested enough to check everyone else's work. In the case of OpenSSL, we've found that some projects become so complex that almost nobody does for long periods of time.
    - Hizonner 4y ago
      I think the thing that makes it more tractable in pure languages is that you at least get the chance to control the dependency's inputs and inspect all of its outputs, so it's theoretically possible to limit what it can do to you (depending on how you are using those outputs). I'm not saying it's usually practical, but it's at least conceivable. And there should be at least a few cases where it's actually practical. In an impure language, it can do any random thing to any random part of the whole system and you won't even get the chance to know what it is doing. Are there any truly pure package management systems out there, though? Haskell has Safe Haskell, which more or less guarantees that the actual Haskell code compiled through the normal path is pure (but not that the code is total, and total under resource constraints, which you also need). The build system itself is not pure, though, so you have no guarantee that a dependency's build scripts don't put Evil Things into your program outside of the actual language framework. Any others?
      - remexre 4y ago
        It sounds like Safe Haskell might be getting deprecated soon [0]; it sounds like it isn't used much in practice... [0]: https://discourse.haskell.org/t/deprecating-safe-haskell-or-heavily-investing-in-it/5489/ https://discourse.haskell.org/t/deprecating-safe-haskell-or-...
    - bhickey 4y ago
      > not just with side effects I think you're using "side effects" in a colloquial sense while I'm using it in a PL sense. Pure code is deterministic, operating only on its params. Impure code—code with side effects—is something that depends on state outside of its parameters.
    - simne 4y ago
      > Our package managers operate entirely on trust Cannot agree with this oversimplification. Exists community. Yes, every human have his own motives, but many live in countries with effective law enforcement, and many people obey Western Values. Also important, software is a chain with many parts, some parts of one chain could make really large disruptions, some are less significant. So overall, real formula includes trust, humanity values, laws, government effectiveness and inertia of this chain.
  - TAForObvReasons 4y ago
    Rust : Cargo :: Haskell : Hackage . It's extremely easy to add dependencies and that problem is independent of purity. As an example of an "impure language" with security in the form you envision, Deno allows you to specify access controls on a per-script or per-dependency basis. You can specify imports that prevent dependencies from opening sockets or writing files or reading files. Many years ago npm inc treated download and package counts as KPI. They pushed back against sensible measures like code signing, instead centralizing the ecosystem and encouraging cross-dependencies within their registry. A more security-oriented package manager would have focused on code signing and vendoring strategies.
    - bhickey 4y ago
      Haskell is largely pure. There's nothing in place to stop a dependency from putting unsafePerformIO on blast. If a dependency can only do pure functional computation then the worst things it can do are like (1+1=4) or diverge. From your description it sounds like Deno is using object capabilities -- that's a great step forward. > Many years ago npm inc treated download and package counts as KPI. That's bonkers. I had no idea.
      - Hizonner 4y ago
        > There's nothing in place to stop a dependency from putting unsafePerformIO on blast. import safe MyDependency ... but do you have to make sure that nothing in the tree is claiming to be Trustworthy. Which is actually pretty easy.
      - ryukafalz 4y ago
        I believe GP misspoke; to my knowledge Deno does not allow you to set permissions on dependencies. It's not using object capabilities as far as I'm aware. I wish it were! https://github.com/denoland/deno/issues/171 https://github.com/denoland/deno/issues/171
gizmo686 4y ago
Its not intractable. You just need to take the concept of a software supply chain seriously. E.G, every version of every dependency you use (either directly or transitivly) needs to be audited and approved by a trusted supplier. This isn't nearly as bad as it sounds. You only need 1 trusted organization across the entire industry to certify a baseline of trusted software. Maybe a second organization to cover people who don't trust the first. The NSA, some other part of US cyber command, or a comparable agency from a different government are all natural choices; as they have a vested interest in protecting critical domestic infrastructure but no commercial interest in keeping their work proprietary. Since that infrastructure all runs the same software as the rest of industry, we all benefit.
- dragonwriter 4y ago
  > The NSA, some other part of US cyber command, or a comparable agency from a different government are all natural choices; as they have a vested interest in protecting critical domestic infrastructure NSA is not a natural choice, since they are an active threat that has a history of abusing trust in their defensive mandate to insert vulnerabilities into systems in pursuit of their offensive mission.
  - lrhegeba 4y ago
    Then you can decide for your org to not trust them and perhaps use a different certifier. i would welcome them offering such a service instead of having none.
    - voakbasda 4y ago
      Trust like this is transitive, so I would not trust any organization that placed such blind faith in the NSA. I hope your brave new world includes a requirement for orgs to disclose their software auditor, so my org can avoid trusting orgs like yours.
- Hizonner 4y ago
  > You only need 1 trusted organization across the entire industry to certify a baseline of trusted software. So it's not just bad, but impossible. Got it. More to the point, software "auditing" does not work reliably against deliberately malicious code written by competent actors, never has, and never will. It's too easy to slip in subtle back doors that reviewers won't notice, and at the same time too hard to keep up with the review workload.
di4na 4y ago
Author here. You do realise that the main source of dangerous vulnerability is low level infrastructure that do not come from these package managers ? The purity and capabilities sadly solve nothing when the source of the problem is the fact that NTP, OpenSSL, OpenSSH, the BGP daemon, the libc you run on, etc are all maintained and "fixed" and evolved by people that can barely pay for their food, even less for basic tests ? Like i love capabilities and i would love to have more, but the basic problem here is that the low level that you totally depend on for the capabilities to work cannot even be funded to work. Hell you do realise that Autoconf has not had a maintainer since 2012? If it was pwned and had injected backdoor in your software since then, we would have noone to fix it.
- asdfghjhgfderty 4y ago
  nonsense. autoconf didn't have a core developer. But it had many distro package managers. there's nobody adding code/fixing bugs, but there are plenty people reading and looking at diffs before packaging it in distros. then the js libs have neither core maintainers nor anybody at npm corp that cares about security or reading anything. the top comment is correct to care about those before system libraries.
  - kelnos 4y ago
    I don't agree. When there's a problem in OpenSSL, OpenSSH, or libc, nearly every company with an online presence has as freak-out and rushes to patch. When there's a vulnerability or malware found in a python or npm package, 75% of the tech world does a quick audit (or not), shrugs, and goes on with their day.
  - gsich 4y ago
    Why the weak words? "reading", "looking" is not "understanding".
    - pbhjpbhj 4y ago
      IANADev, but surely if they were going as deep as understanding patches they'd practically be a project maintainer rather than a package maintainer. Expecting package maintainers to have even reviewed diffs seems like high expectations. I wouldn't expect them to do more than the actual packaging. Weak words seem appropriate. I've hacked together a couple of packages for personal use but didn't even go so far at to look what language the code was in. I'm assuming a lot of packages from ppa-s are produced in an automated way with no code review, and depending on your distro that might also be true of some principal libraries.
tsimionescu 4y ago
Can you give some examples of such a pure language? Haskell is definitely not it, since you can always call unsafePerformIO anywhere to do anything. I would guess Idris has something similar, but maybe I'm wrong. Also, if a dependency actually needs IO (either a networking library, or a DB library, or just for logging purposes), the guarantees you're talking about again go out the window. And, moving to the more extreme scale, you can never be 100% sure that some dependency hasn't found a way to trick the compiler or runtime system into doing something it's not supposed to be possible to do, even if it consists of (ostensibly) pure code only.
- bhickey 4y ago
  > Can you give some examples of such a pure language? BPF and eBPF, though this feels unsatisfying.
sethammons 4y ago
Hence why I check in vendor dependencies. It is wild to me that people pull fresh their dependencies on builds, trusting patch versions that really should have been major versions.
- lucasyvas 4y ago
  Vendoring is an option, but if you place some trust in your registry a lockfile is totally fine.
yencabulator 4y ago
Functional purity is the wrong abstraction to ask for, and doesn't protect you as such (consider a Haskell library that, very purely, asks to write to ~/.bashrc). Sandboxing modules is what you want, and that can be done with impure languages too. Sure, pure functional programming might make it easier, but as others pointed out, Safe Haskell and friends are very very far from mainstream. Meanwhile, Firefox compiles some C/C++ dependencies into wasm, and runs them in sandboxes.

TAForObvReasons 4y ago

the current fragility of the "software supply chain" stems from package managers and their perverse economic incentives, and this is just as true for "pure languages". Vendoring and auditing dependencies greatly reduces the attack surface area.

bhickey 4y ago
Can you elaborate on the incentives of package managers? The problem I see with Rust is that it's just really easy to add dependebcies in a way that is difficult in C++. I don't follow your point about purity. A dependency in a side-effect free language can't suddenly open a socket or access the file system. The attack surface is much smaller.
- busterarm 4y ago
  > A dependency in a side-effect free language can't suddenly open a socket or access the file system. A dependency can exploit your system deliberately, not just with side effects. If you're not strictly pinning all of your dependency versions, one malicious update that makes it to the package manager can ruin your whole world. Our package managers operate entirely on trust. Nobody is guaranteed to be checking to make sure some random package's maintainer isn't submitting malicious updates. As a community we're all lazy and basically hope that somebody else is invested enough to check everyone else's work. In the case of OpenSSL, we've found that some projects become so complex that almost nobody does for long periods of time.
  - Hizonner 4y ago
    I think the thing that makes it more tractable in pure languages is that you at least get the chance to control the dependency's inputs and inspect all of its outputs, so it's theoretically possible to limit what it can do to you (depending on how you are using those outputs). I'm not saying it's usually practical, but it's at least conceivable. And there should be at least a few cases where it's actually practical. In an impure language, it can do any random thing to any random part of the whole system and you won't even get the chance to know what it is doing. Are there any truly pure package management systems out there, though? Haskell has Safe Haskell, which more or less guarantees that the actual Haskell code compiled through the normal path is pure (but not that the code is total, and total under resource constraints, which you also need). The build system itself is not pure, though, so you have no guarantee that a dependency's build scripts don't put Evil Things into your program outside of the actual language framework. Any others?
    - remexre 4y ago
      It sounds like Safe Haskell might be getting deprecated soon [0]; it sounds like it isn't used much in practice... [0]: https://discourse.haskell.org/t/deprecating-safe-haskell-or-heavily-investing-in-it/5489/ https://discourse.haskell.org/t/deprecating-safe-haskell-or-...
  - bhickey 4y ago
    > not just with side effects I think you're using "side effects" in a colloquial sense while I'm using it in a PL sense. Pure code is deterministic, operating only on its params. Impure code—code with side effects—is something that depends on state outside of its parameters.
  - simne 4y ago
    > Our package managers operate entirely on trust Cannot agree with this oversimplification. Exists community. Yes, every human have his own motives, but many live in countries with effective law enforcement, and many people obey Western Values. Also important, software is a chain with many parts, some parts of one chain could make really large disruptions, some are less significant. So overall, real formula includes trust, humanity values, laws, government effectiveness and inertia of this chain.
- TAForObvReasons 4y ago
  Rust : Cargo :: Haskell : Hackage . It's extremely easy to add dependencies and that problem is independent of purity. As an example of an "impure language" with security in the form you envision, Deno allows you to specify access controls on a per-script or per-dependency basis. You can specify imports that prevent dependencies from opening sockets or writing files or reading files. Many years ago npm inc treated download and package counts as KPI. They pushed back against sensible measures like code signing, instead centralizing the ecosystem and encouraging cross-dependencies within their registry. A more security-oriented package manager would have focused on code signing and vendoring strategies.
  - bhickey 4y ago
    Haskell is largely pure. There's nothing in place to stop a dependency from putting unsafePerformIO on blast. If a dependency can only do pure functional computation then the worst things it can do are like (1+1=4) or diverge. From your description it sounds like Deno is using object capabilities -- that's a great step forward. > Many years ago npm inc treated download and package counts as KPI. That's bonkers. I had no idea.
    - Hizonner 4y ago
      > There's nothing in place to stop a dependency from putting unsafePerformIO on blast. import safe MyDependency ... but do you have to make sure that nothing in the tree is claiming to be Trustworthy. Which is actually pretty easy.
    - ryukafalz 4y ago
      I believe GP misspoke; to my knowledge Deno does not allow you to set permissions on dependencies. It's not using object capabilities as far as I'm aware. I wish it were! https://github.com/denoland/deno/issues/171 https://github.com/denoland/deno/issues/171

gizmo686 4y ago

Its not intractable. You just need to take the concept of a software supply chain seriously. E.G, every version of every dependency you use (either directly or transitivly) needs to be audited and approved by a trusted supplier. This isn't nearly as bad as it sounds. You only need 1 trusted organization across the entire industry to certify a baseline of trusted software. Maybe a second organization to cover people who don't trust the first. The NSA, some other part of US cyber command, or a comparable agency from a different government are all natural choices; as they have a vested interest in protecting critical domestic infrastructure but no commercial interest in keeping their work proprietary. Since that infrastructure all runs the same software as the rest of industry, we all benefit.

dragonwriter 4y ago
> The NSA, some other part of US cyber command, or a comparable agency from a different government are all natural choices; as they have a vested interest in protecting critical domestic infrastructure NSA is not a natural choice, since they are an active threat that has a history of abusing trust in their defensive mandate to insert vulnerabilities into systems in pursuit of their offensive mission.
- lrhegeba 4y ago
  Then you can decide for your org to not trust them and perhaps use a different certifier. i would welcome them offering such a service instead of having none.
  - voakbasda 4y ago
    Trust like this is transitive, so I would not trust any organization that placed such blind faith in the NSA. I hope your brave new world includes a requirement for orgs to disclose their software auditor, so my org can avoid trusting orgs like yours.
Hizonner 4y ago
> You only need 1 trusted organization across the entire industry to certify a baseline of trusted software. So it's not just bad, but impossible. Got it. More to the point, software "auditing" does not work reliably against deliberately malicious code written by competent actors, never has, and never will. It's too easy to slip in subtle back doors that reviewers won't notice, and at the same time too hard to keep up with the review workload.

di4na 4y ago

Author here. You do realise that the main source of dangerous vulnerability is low level infrastructure that do not come from these package managers ? The purity and capabilities sadly solve nothing when the source of the problem is the fact that NTP, OpenSSL, OpenSSH, the BGP daemon, the libc you run on, etc are all maintained and "fixed" and evolved by people that can barely pay for their food, even less for basic tests ? Like i love capabilities and i would love to have more, but the basic problem here is that the low level that you totally depend on for the capabilities to work cannot even be funded to work. Hell you do realise that Autoconf has not had a maintainer since 2012? If it was pwned and had injected backdoor in your software since then, we would have noone to fix it.

asdfghjhgfderty 4y ago
nonsense. autoconf didn't have a core developer. But it had many distro package managers. there's nobody adding code/fixing bugs, but there are plenty people reading and looking at diffs before packaging it in distros. then the js libs have neither core maintainers nor anybody at npm corp that cares about security or reading anything. the top comment is correct to care about those before system libraries.
- kelnos 4y ago
  I don't agree. When there's a problem in OpenSSL, OpenSSH, or libc, nearly every company with an online presence has as freak-out and rushes to patch. When there's a vulnerability or malware found in a python or npm package, 75% of the tech world does a quick audit (or not), shrugs, and goes on with their day.
- gsich 4y ago
  Why the weak words? "reading", "looking" is not "understanding".
  - pbhjpbhj 4y ago
    IANADev, but surely if they were going as deep as understanding patches they'd practically be a project maintainer rather than a package maintainer. Expecting package maintainers to have even reviewed diffs seems like high expectations. I wouldn't expect them to do more than the actual packaging. Weak words seem appropriate. I've hacked together a couple of packages for personal use but didn't even go so far at to look what language the code was in. I'm assuming a lot of packages from ppa-s are produced in an automated way with no code review, and depending on your distro that might also be true of some principal libraries.

tsimionescu 4y ago

Can you give some examples of such a pure language? Haskell is definitely not it, since you can always call unsafePerformIO anywhere to do anything. I would guess Idris has something similar, but maybe I'm wrong. Also, if a dependency actually needs IO (either a networking library, or a DB library, or just for logging purposes), the guarantees you're talking about again go out the window. And, moving to the more extreme scale, you can never be 100% sure that some dependency hasn't found a way to trick the compiler or runtime system into doing something it's not supposed to be possible to do, even if it consists of (ostensibly) pure code only.

bhickey 4y ago
> Can you give some examples of such a pure language? BPF and eBPF, though this feels unsatisfying.

sethammons 4y ago

Hence why I check in vendor dependencies. It is wild to me that people pull fresh their dependencies on builds, trusting patch versions that really should have been major versions.

lucasyvas 4y ago
Vendoring is an option, but if you place some trust in your registry a lockfile is totally fine.

yencabulator 4y ago

Functional purity is the wrong abstraction to ask for, and doesn't protect you as such (consider a Haskell library that, very purely, asks to write to ~/.bashrc). Sandboxing modules is what you want, and that can be done with impure languages too. Sure, pure functional programming might make it easier, but as others pointed out, Safe Haskell and friends are very very far from mainstream. Meanwhile, Firefox compiles some C/C++ dependencies into wasm, and runs them in sandboxes.