3 ms·

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 fro

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.

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.