6 ms·

This idea seems surprising: « you’d be crazy to think hardware was ever intended to be used for isolating multiple users safely » Surely the era where it was c

This idea seems surprising: « you’d be crazy to think hardware was ever intended to be used for isolating multiple users safely » Surely the era where it was common for multiple users to be logging into one computer was long enough, and central enough, that it still informs a great deal of current hardware design.

wmf 8y ago
I thought the consensus was more like: multi-user security is a solved problem except for side channels which are everywhere, there's nothing you can do about them, and they're impractical to exploit. That last part turned out to be wrong.
- rbanffy 8y ago
  You can have physical partitioning on very high-end machines.
  - GauntletWizard 8y ago
    You can have physical partitioning on low end machines, too. The cpuset cgroup allows you to partition processes so that they only run on certain cores, and then you can prevent them from accessing memory through other cores, and and and... And you'll still find side channel attacks that you didn't think of, because the system is complex. Or you can buy a dozen cheap systems and run each of your customers on one of those. There's still the opportunity for side channels there - We were finding timing exploits in crypto libraries long before VMs. It's an arms race, and we're neither winning or losing, but as the market grows the spread gets wider.
- cryptonector 8y ago
  > The last pare turned out to be wrong ...and that upended everything about CPU multi-tenancy.
- marcosdumay 8y ago
  > That last part turned out to be wrong. Well, it was true when the abstract machine described by a CPU datasheet was closer to the one actually running the code. But people decided it was better to run all the code through a real-time optimizing interpreter, and didn't check the interpreter for security. We'll get secure machines back at some point. One or two manufacturers may die on the process.
- nickpsecurity 8y ago
  If they secure the hardware, that was known true as of early 1990's in VAX VMM. The only thing they couldn't eradicate was the timing channels in CPU's (esp caches) and system. They could just minimize bandwidth per TCSEC certification requirements. Stopping leaks had negative impacts on performance, though. They found plenty in the Intel processors later calling for making them leak-proof. Physical partitioning with optical connections is still best. Add TEMPEST shielding and power filtering if on high end. https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua... http://lukemuehlhauser.com/wp-content/uploads/Karger-et-al-A-retrospective-on-the-VAX-VMM-security-kernel.pdf http://lukemuehlhauser.com/wp-content/uploads/Karger-et-al-A... https://ieeexplore.ieee.org/document/213271 https://ieeexplore.ieee.org/document/213271 https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f653... Industry and hackers just ignored this stuff for different reasons. The TCSEC certification, despite its problems, cause those along with all kinds of vulnerabilities by forcing systematic design and evaluation with methods proven to get the job done. NSA pentesters shredded most commercial products during evaluation. Today's still do for lots of F/OSS, too. The B3/A1, or high-assurance, systems took 2-5 years of pentesting with hardly any issues found. Details were published in conferences and products marketed. Aside from formal verification, only apathy explains security-focused folks totally ignoring all that outside CompSci which often cites it. What's causing the problem Jessie Frazel speculates about is merely that people running companies are incentivized to not give a damn in all kinds of ways. That includes adding insecure features to drive sales (mgmt bonus), cutting or ignoring security along with other costs (mgmt bonus), and no liability for damage that happens (externalities). The solution is, like TCSEC or DO-178C, carefully-designed regulations that force them to use known-good methods to knock out preventable problems. If they don't, the fines are higher than the cost of preventing them. That and/or liability in court for anything they could afford to use. Obviously, we might make provisions for smaller businesses that had less money for consultations. A lot of what we see in the marketplace, though, is avoidable with almost no effort. Free guides experts keep up to date on the basics might constitute the minimum with liability going up based on what resources they had available to do more. Reusable solutions and solution providers would show up to make it easier like they did for both TCSEC and DO-178C (still do for it). There's also existing offerings that are more secure-by-default which can be extended. On native side, you have stuff like OpenBSD, lwan web server, and TrustDNS in Rust. Even PHP has Airship CMS to help people throw web apps together with fewer problems. These companies will come around when they're forced to come around with the threat CEO's, project managers, and others will loose their money and/or position for not having security. Before that, they'll try to bribe, argue in court, bullshit, and so on. There will be some fight to get there. Lots of improvements such as no telnet on routers can come with almost no money spent. We might make progress by just reminding decision makers during those battles how inexpensive certain improvements really are vs the regulatory and legal actions.
skywhopper 8y ago
The hardware that was built for multiuser operation existed, for sure, but it lost out to up-jumped desktop CPUs that tried to paste it over the top of a single-user core design. But more importantly, the tricks employed to get around the physical limits of straightforward speed scaling worked by going around that pasted-on layer of security.
- wmf 8y ago
  IBM seems to have no official statement about whether z is vulnerable to Spectre but Power7/8/9 are/were definitely affected. Fujitsu SPARC is also vulnerable but interestingly Oracle SPARC is not. If Alpha, MIPS, or PA-RISC still existed I would expect most of them to be vulnerable as well. Are there specific hardware mechanisms in "real" server processors that can provide high performance without side channels? What are they?
  - nickpsecurity 8y ago
    I wouldn't trust them. One might mitigate a bit using the classic patterns against side channels: randomization and masking. I came up with an idea for randomizing execution at CPU level but the person that beat me to it patented it. Possibly something like ARINC partitioning combined with randomization plus operations similar to those that process secrets, but process fake data. One of the simplest methods, though, is focusing the leak-proofing on the barrier between partitions handling secrets and everything else (esp w/ comms capability). Then, you just make sure you have trusted, hard-to-hack code on as much of the system as possible. No web browsers and such. Safe, system language with pointer and overflow protections along with performance hit that comes with. Otherwise, back to physical separation. I used that with KVM switch back in the day.
  - int_19h 8y ago
    MIPS still exists, it's not uncommon in cheap routers. Here's their statement on vulnerabilities: https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/ https://www.mips.com/blog/mips-response-on-speculative-execu...

wmf 8y ago

I thought the consensus was more like: multi-user security is a solved problem except for side channels which are everywhere, there's nothing you can do about them, and they're impractical to exploit. That last part turned out to be wrong.

rbanffy 8y ago
You can have physical partitioning on very high-end machines.
- GauntletWizard 8y ago
  You can have physical partitioning on low end machines, too. The cpuset cgroup allows you to partition processes so that they only run on certain cores, and then you can prevent them from accessing memory through other cores, and and and... And you'll still find side channel attacks that you didn't think of, because the system is complex. Or you can buy a dozen cheap systems and run each of your customers on one of those. There's still the opportunity for side channels there - We were finding timing exploits in crypto libraries long before VMs. It's an arms race, and we're neither winning or losing, but as the market grows the spread gets wider.
cryptonector 8y ago
> The last pare turned out to be wrong ...and that upended everything about CPU multi-tenancy.
marcosdumay 8y ago
> That last part turned out to be wrong. Well, it was true when the abstract machine described by a CPU datasheet was closer to the one actually running the code. But people decided it was better to run all the code through a real-time optimizing interpreter, and didn't check the interpreter for security. We'll get secure machines back at some point. One or two manufacturers may die on the process.
nickpsecurity 8y ago
If they secure the hardware, that was known true as of early 1990's in VAX VMM. The only thing they couldn't eradicate was the timing channels in CPU's (esp caches) and system. They could just minimize bandwidth per TCSEC certification requirements. Stopping leaks had negative impacts on performance, though. They found plenty in the Intel processors later calling for making them leak-proof. Physical partitioning with optical connections is still best. Add TEMPEST shielding and power filtering if on high end. https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua... http://lukemuehlhauser.com/wp-content/uploads/Karger-et-al-A-retrospective-on-the-VAX-VMM-security-kernel.pdf http://lukemuehlhauser.com/wp-content/uploads/Karger-et-al-A... https://ieeexplore.ieee.org/document/213271 https://ieeexplore.ieee.org/document/213271 https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f653... Industry and hackers just ignored this stuff for different reasons. The TCSEC certification, despite its problems, cause those along with all kinds of vulnerabilities by forcing systematic design and evaluation with methods proven to get the job done. NSA pentesters shredded most commercial products during evaluation. Today's still do for lots of F/OSS, too. The B3/A1, or high-assurance, systems took 2-5 years of pentesting with hardly any issues found. Details were published in conferences and products marketed. Aside from formal verification, only apathy explains security-focused folks totally ignoring all that outside CompSci which often cites it. What's causing the problem Jessie Frazel speculates about is merely that people running companies are incentivized to not give a damn in all kinds of ways. That includes adding insecure features to drive sales (mgmt bonus), cutting or ignoring security along with other costs (mgmt bonus), and no liability for damage that happens (externalities). The solution is, like TCSEC or DO-178C, carefully-designed regulations that force them to use known-good methods to knock out preventable problems. If they don't, the fines are higher than the cost of preventing them. That and/or liability in court for anything they could afford to use. Obviously, we might make provisions for smaller businesses that had less money for consultations. A lot of what we see in the marketplace, though, is avoidable with almost no effort. Free guides experts keep up to date on the basics might constitute the minimum with liability going up based on what resources they had available to do more. Reusable solutions and solution providers would show up to make it easier like they did for both TCSEC and DO-178C (still do for it). There's also existing offerings that are more secure-by-default which can be extended. On native side, you have stuff like OpenBSD, lwan web server, and TrustDNS in Rust. Even PHP has Airship CMS to help people throw web apps together with fewer problems. These companies will come around when they're forced to come around with the threat CEO's, project managers, and others will loose their money and/or position for not having security. Before that, they'll try to bribe, argue in court, bullshit, and so on. There will be some fight to get there. Lots of improvements such as no telnet on routers can come with almost no money spent. We might make progress by just reminding decision makers during those battles how inexpensive certain improvements really are vs the regulatory and legal actions.

skywhopper 8y ago

The hardware that was built for multiuser operation existed, for sure, but it lost out to up-jumped desktop CPUs that tried to paste it over the top of a single-user core design. But more importantly, the tricks employed to get around the physical limits of straightforward speed scaling worked by going around that pasted-on layer of security.

wmf 8y ago
IBM seems to have no official statement about whether z is vulnerable to Spectre but Power7/8/9 are/were definitely affected. Fujitsu SPARC is also vulnerable but interestingly Oracle SPARC is not. If Alpha, MIPS, or PA-RISC still existed I would expect most of them to be vulnerable as well. Are there specific hardware mechanisms in "real" server processors that can provide high performance without side channels? What are they?
- nickpsecurity 8y ago
  I wouldn't trust them. One might mitigate a bit using the classic patterns against side channels: randomization and masking. I came up with an idea for randomizing execution at CPU level but the person that beat me to it patented it. Possibly something like ARINC partitioning combined with randomization plus operations similar to those that process secrets, but process fake data. One of the simplest methods, though, is focusing the leak-proofing on the barrier between partitions handling secrets and everything else (esp w/ comms capability). Then, you just make sure you have trusted, hard-to-hack code on as much of the system as possible. No web browsers and such. Safe, system language with pointer and overflow protections along with performance hit that comes with. Otherwise, back to physical separation. I used that with KVM switch back in the day.
- int_19h 8y ago
  MIPS still exists, it's not uncommon in cheap routers. Here's their statement on vulnerabilities: https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/ https://www.mips.com/blog/mips-response-on-speculative-execu...