5 ms·

The only practical way is to have a centralized vetting organization that can give a trusted stamp of approval to signed packages. That would still slow things

by tux1968 6y ago

The only practical way is to have a centralized vetting organization that can give a trusted stamp of approval to signed packages. That would still slow things down, but at least wouldn't require duplication of work by everyone on a massive scale. You could outsource your vetting work to a distribution you trust.

artful-hacker 6y ago
I was trying to find a solution to this problem for my organization and came across https://tidelift.com/ https://tidelift.com/. I like some of their ideas and think it's a solid path forward at chipping away on this issue. https://libraries.io/ https://libraries.io/ is a project of theirs I use quite often when vetting third party dependencies for our organization.
JulianMorrison 6y ago
The issue that runs into is a mirror of the one raised by the pyca/cryptography business. For which CPU and hardware architecture should they be verified? On which OS? With which set of dependencies, including dependencies on non-Python compiled libraries? Presumably all of those will need to be verified as well, and the problem recurses.
- freeone3000 6y ago
  Every different CPU architecture and OS architecture is a different package. Software distributions already know this. The individual packages need to be verified.
  - vel0city 6y ago
    At least with Python, this is true only if you're installing pre-compiled wheels which is quickly become more and more the norm. For a while though several packages were compile on install so you wouldn't necessarily have a different package per architecture/OS combination.
    - freeone3000 6y ago
      You don't have a different package name, but you for sure have a different package. Take, for instance, the keyword "long". 64 bit on amd64, 32-bit on armhf. So even source distributions to be compiled locally differ based on target, even if they have the same coordinates in pypy.
      - vel0city 6y ago
        I agree the resulting binaries will be different but I disagree that these are then different packages. The package is whatever the distributor distributed it as. They distributed it as source, which you took and compiled to your local binary version. With "The individual packages need to be verified", and each resulting different binary being uniquely a different package, this means the package/repo maintainer of a source package would need to verify it for every single platform which compiles C and every potential compiler and every potential set of flags for the compiler as each set of platform/compiler/flags could result in a different binary and thus different behavior.
        freeone3000 6y ago
        Yeah, if I were setting up a verification service there's no way I would verify source code instead of compiled binaries.
adolph 6y ago
That sounds like it would have the app store problem. If you are successful, you are a monopoly target. If you miss an attack, you are to blame. If you don't approve fast enough, you are blocking.
- tux1968 6y ago
  The entire point of such an organization would be to accept the blame if an attack was missed. But there should be no natural monopoly since anyone could offer this vetting service. And as an end user there would be nothing preventing you from circumventing the repository of such a service (except for the risk you'd be taking on for yourself).
  - adolph 6y ago
    Scapegoat as a Service?
    - tux1968 6y ago
      Sure, you could look at it like that. But their only value would be if they're never (or at least very rarely) actually called upon to act as a scapegoat. All the incentives would be for them to do their job and keep compromised software out of the ecosystem. Of course nobody is perfect, but they couldn't be flippant about it and survive.
      - uranusjr 6y ago
        What are the incentives? I honestly can’t tell.
        tux1968 6y ago
        The only reason for such an organization to exist is to be a clearing house for software; adding a stamp of approval that it is safe and hasn't been compromised by nefarious actors. Such an organization might be funded by a trade association, industry sponsorship, or direct fees to end users. But whatever the case, it would be strongly incentivized to fulfill its mandate or else lose credibility, reputation, influence, and financial rewards.
shrimp_emoji 6y ago
The only practical way is to run all software in sandboxed containers that statically link everything they need and cannot harm the system via bugs/exploits from outdated/compromised libs. In the past, there wasn't much software or much memory, and software was simple. Now, memory is plentiful, there's too much software, and software is too complex. A central authority doesn't scale. Fixing our naivete about how much to trust software does.
- tux1968 6y ago
  You're definitely right that decreasing the attack surface will be an important element to improving the situation, but it doesn't really solve the problem completely. Software will always need operational room to do anything useful and in so doing will still offer an opportunity for exploitation. Increasing the trust we are able to place in the tools and libraries we leverage isn't a complete solution either, but it will have to be an element. Currently we've got nothing but blind faith and crossed fingers.
- vel0city 6y ago
  Software that I can't put data into or take data out of isn't very useful. You can mitigate the splash damage something could do and reduce the attack surface, but at some point I'm probably going to be feeding that process some files or data stream and I'm going to have it write out some files or data stream. Those data entry and exit points are still exploitable, or acting on the data stream could be harmful. Sandboxing is good to do, but ultimately isn't the solution to the problem of malicious code. Otherwise its pretty much just a space heater.
  - contravariant 6y ago
    I can kind of see what you're getting at but a pure function can both accept and return data without any risk of this data leaking anywhere unintended.
    - vel0city 6y ago
      Data leaking isn't the only thing you may be worried about. What about a random number generator designed as a pure function that skews a certain way reducing your cryptographic integrity? What if what looks like a pure function from the outside you're using for some range estimate on some ballistic payload is able to detect its in a live fire scenario and changes its outputs leading to inaccurate detonation? We're talking about malicious external packages/libraries and what not coming in, assuming everything is a pure function in the compiled black box of obfuscated code probably isn't a winning strategy on keeping your system secure. Of course, everyone's threat profile and the risks of failure vary greatly based on the application being deployed.

artful-hacker 6y ago

I was trying to find a solution to this problem for my organization and came across https://tidelift.com/ https://tidelift.com/. I like some of their ideas and think it's a solid path forward at chipping away on this issue. https://libraries.io/ https://libraries.io/ is a project of theirs I use quite often when vetting third party dependencies for our organization.

JulianMorrison 6y ago

The issue that runs into is a mirror of the one raised by the pyca/cryptography business. For which CPU and hardware architecture should they be verified? On which OS? With which set of dependencies, including dependencies on non-Python compiled libraries? Presumably all of those will need to be verified as well, and the problem recurses.

freeone3000 6y ago
Every different CPU architecture and OS architecture is a different package. Software distributions already know this. The individual packages need to be verified.
- vel0city 6y ago
  At least with Python, this is true only if you're installing pre-compiled wheels which is quickly become more and more the norm. For a while though several packages were compile on install so you wouldn't necessarily have a different package per architecture/OS combination.
  - freeone3000 6y ago
    You don't have a different package name, but you for sure have a different package. Take, for instance, the keyword "long". 64 bit on amd64, 32-bit on armhf. So even source distributions to be compiled locally differ based on target, even if they have the same coordinates in pypy.
    - vel0city 6y ago
      I agree the resulting binaries will be different but I disagree that these are then different packages. The package is whatever the distributor distributed it as. They distributed it as source, which you took and compiled to your local binary version. With "The individual packages need to be verified", and each resulting different binary being uniquely a different package, this means the package/repo maintainer of a source package would need to verify it for every single platform which compiles C and every potential compiler and every potential set of flags for the compiler as each set of platform/compiler/flags could result in a different binary and thus different behavior.
      - freeone3000 6y ago
        Yeah, if I were setting up a verification service there's no way I would verify source code instead of compiled binaries.

adolph 6y ago

That sounds like it would have the app store problem. If you are successful, you are a monopoly target. If you miss an attack, you are to blame. If you don't approve fast enough, you are blocking.

tux1968 6y ago
The entire point of such an organization would be to accept the blame if an attack was missed. But there should be no natural monopoly since anyone could offer this vetting service. And as an end user there would be nothing preventing you from circumventing the repository of such a service (except for the risk you'd be taking on for yourself).
- adolph 6y ago
  Scapegoat as a Service?
  - tux1968 6y ago
    Sure, you could look at it like that. But their only value would be if they're never (or at least very rarely) actually called upon to act as a scapegoat. All the incentives would be for them to do their job and keep compromised software out of the ecosystem. Of course nobody is perfect, but they couldn't be flippant about it and survive.
    - uranusjr 6y ago
      What are the incentives? I honestly can’t tell.
      - tux1968 6y ago
        The only reason for such an organization to exist is to be a clearing house for software; adding a stamp of approval that it is safe and hasn't been compromised by nefarious actors. Such an organization might be funded by a trade association, industry sponsorship, or direct fees to end users. But whatever the case, it would be strongly incentivized to fulfill its mandate or else lose credibility, reputation, influence, and financial rewards.

shrimp_emoji 6y ago

The only practical way is to run all software in sandboxed containers that statically link everything they need and cannot harm the system via bugs/exploits from outdated/compromised libs. In the past, there wasn't much software or much memory, and software was simple. Now, memory is plentiful, there's too much software, and software is too complex. A central authority doesn't scale. Fixing our naivete about how much to trust software does.

tux1968 6y ago
You're definitely right that decreasing the attack surface will be an important element to improving the situation, but it doesn't really solve the problem completely. Software will always need operational room to do anything useful and in so doing will still offer an opportunity for exploitation. Increasing the trust we are able to place in the tools and libraries we leverage isn't a complete solution either, but it will have to be an element. Currently we've got nothing but blind faith and crossed fingers.
vel0city 6y ago
Software that I can't put data into or take data out of isn't very useful. You can mitigate the splash damage something could do and reduce the attack surface, but at some point I'm probably going to be feeding that process some files or data stream and I'm going to have it write out some files or data stream. Those data entry and exit points are still exploitable, or acting on the data stream could be harmful. Sandboxing is good to do, but ultimately isn't the solution to the problem of malicious code. Otherwise its pretty much just a space heater.
- contravariant 6y ago
  I can kind of see what you're getting at but a pure function can both accept and return data without any risk of this data leaking anywhere unintended.
  - vel0city 6y ago
    Data leaking isn't the only thing you may be worried about. What about a random number generator designed as a pure function that skews a certain way reducing your cryptographic integrity? What if what looks like a pure function from the outside you're using for some range estimate on some ballistic payload is able to detect its in a live fire scenario and changes its outputs leading to inaccurate detonation? We're talking about malicious external packages/libraries and what not coming in, assuming everything is a pure function in the compiled black box of obfuscated code probably isn't a winning strategy on keeping your system secure. Of course, everyone's threat profile and the risks of failure vary greatly based on the application being deployed.