5 ms·

I wonder if there's a sort of 'herd immunity' effect that would reduce your risk of not running the mitigations. Since the assumption is that this class of expl

I wonder if there's a sort of 'herd immunity' effect that would reduce your risk of not running the mitigations. Since the assumption is that this class of exploit is known and patched, it might be less attractive for exploit makers to target. Given that, you can actually disable the mitigation to get the performance back without suffering a breach. I wouldn't do this at a data center or a nuclear powerplant, but for personal workloads like gaming this might be an okay tradeoff.

CogitoCogito 7y ago
This is basically one of the arguments why Linux doesn't have as many exploits. If Linux were in more widespread usage, then more focus would be put on exploiting it and hence running it without e.g. anti-virus or other mechanisms would be more dangerous. So Linux's relative market share might protect it more than many security choices in the OS. (I don't want to claim that any of the reasoning here is true, but I just wanted to point out the parallel to what you're saying.)
scandinavian 7y ago
Well, it remains to be seen if someone can even mount and attack against firefox or chrome. The researchers (RIDL) only managed ~1byte/s against a detached spidermonkey engine, with the old high-resolution timer enabled (these have been removed). They were not able to mount an attack against chrome. I have my doubts that we will ever see attempts at widespread exploitation against browsers. So not running mitigations for personal use/gaming would probably be absolutely fine.
- szbalint 7y ago
  Google attempted to fix Chrome against Spectre but gave up, so what you're saying about no feasible attack is not true. See: https://v8.dev/blog/spectre https://v8.dev/blog/spectre > we quickly discovered that software mitigation of all possible leaks due to Spectre was infeasible. Are there many other security issues that are easier to exploit with potentially higher impact? Sure. Does this mean that Spectre is fixed or can be mitigated in software? No. It's a bit like the formerly theoretical timing attacks against TLS: attacks only get better.
  - scandinavian 7y ago
    As said in that very blog, no attacks have been observed. Spectre has been out for a year and a half. Can you show me any indication of any feasible attack on firefox or chrome, that has a PoC or at least proof that it can be utilized for anything remotely useful? However this conversation might be meaningless, as it seems we have a different definition of what constitutes a feasible attack. I still maintain my opinion that not turning on mitigations is safe for personal computing.
    - szbalint 7y ago
      This conversation reminds me of discussions around cryptographic hash functions: https://slideplayer.com/slide/12035043/69/images/28/Reactions+to+stages+in+the+life+cycle+of+cryptographic+hash+functions.jpg https://slideplayer.com/slide/12035043/69/images/28/Reaction... Google clearly considered it an important enough issue to spend considerable resources on trying to mitigate Spectre and in the end only gave up because they didn't find a feasible way to do so. They emphatically didn't conclude that it's fine because attacks are impractical. This attitude was learned the hard way though: about a decade ago the PoC or gtfo attitude was prevalent among browser makers and large tech companies. Theoretical vulnerabilities were dismissed if no immediate proof of concept was provided. What changed this was a bunch of security/cryptographical vulnerabilities. MD5 was known to be theoretically week for years and years, but when researchers minted their "can break every SSL/TLS connection" intermediate certificate to finally make browser vendors move on the issue, it was too late. You see with systemic issues, in cryptography or hardware, by the time you actually demonstrate a PoC, things are way too late: it takes years if not half a decade (as in MD5's case, or with older TLS versions) to deprecate insecure things, if you look at the timelines. So for issues in fundamental building blocks, it's more or less irrelevant if there is a working PoC today or not: if we don't move to fix the underlying issue and start acting on a roadmap to move away from insecure things, people _will_ come up with a working exploit that allows practical attacks. If mitigation is only attempted at that point then we're being left vulnerable for years to come.
      - scandinavian 7y ago
zrm 7y ago
> Since the assumption is that this class of exploit is known and patched, it might be less attractive for exploit makers to target. Given that, you can actually disable the mitigation to get the performance back without suffering a breach. This is an argument that anti-vaxxers use. And it works -- until enough people do it to compromise herd immunity. Then, suddenly, it doesn't work and you have a Very Bad Time.

CogitoCogito 7y ago

This is basically one of the arguments why Linux doesn't have as many exploits. If Linux were in more widespread usage, then more focus would be put on exploiting it and hence running it without e.g. anti-virus or other mechanisms would be more dangerous. So Linux's relative market share might protect it more than many security choices in the OS. (I don't want to claim that any of the reasoning here is true, but I just wanted to point out the parallel to what you're saying.)

scandinavian 7y ago

Well, it remains to be seen if someone can even mount and attack against firefox or chrome. The researchers (RIDL) only managed ~1byte/s against a detached spidermonkey engine, with the old high-resolution timer enabled (these have been removed). They were not able to mount an attack against chrome. I have my doubts that we will ever see attempts at widespread exploitation against browsers. So not running mitigations for personal use/gaming would probably be absolutely fine.

szbalint 7y ago
Google attempted to fix Chrome against Spectre but gave up, so what you're saying about no feasible attack is not true. See: https://v8.dev/blog/spectre https://v8.dev/blog/spectre > we quickly discovered that software mitigation of all possible leaks due to Spectre was infeasible. Are there many other security issues that are easier to exploit with potentially higher impact? Sure. Does this mean that Spectre is fixed or can be mitigated in software? No. It's a bit like the formerly theoretical timing attacks against TLS: attacks only get better.
- scandinavian 7y ago
  As said in that very blog, no attacks have been observed. Spectre has been out for a year and a half. Can you show me any indication of any feasible attack on firefox or chrome, that has a PoC or at least proof that it can be utilized for anything remotely useful? However this conversation might be meaningless, as it seems we have a different definition of what constitutes a feasible attack. I still maintain my opinion that not turning on mitigations is safe for personal computing.
  - szbalint 7y ago
    This conversation reminds me of discussions around cryptographic hash functions: https://slideplayer.com/slide/12035043/69/images/28/Reactions+to+stages+in+the+life+cycle+of+cryptographic+hash+functions.jpg https://slideplayer.com/slide/12035043/69/images/28/Reaction... Google clearly considered it an important enough issue to spend considerable resources on trying to mitigate Spectre and in the end only gave up because they didn't find a feasible way to do so. They emphatically didn't conclude that it's fine because attacks are impractical. This attitude was learned the hard way though: about a decade ago the PoC or gtfo attitude was prevalent among browser makers and large tech companies. Theoretical vulnerabilities were dismissed if no immediate proof of concept was provided. What changed this was a bunch of security/cryptographical vulnerabilities. MD5 was known to be theoretically week for years and years, but when researchers minted their "can break every SSL/TLS connection" intermediate certificate to finally make browser vendors move on the issue, it was too late. You see with systemic issues, in cryptography or hardware, by the time you actually demonstrate a PoC, things are way too late: it takes years if not half a decade (as in MD5's case, or with older TLS versions) to deprecate insecure things, if you look at the timelines. So for issues in fundamental building blocks, it's more or less irrelevant if there is a working PoC today or not: if we don't move to fix the underlying issue and start acting on a roadmap to move away from insecure things, people _will_ come up with a working exploit that allows practical attacks. If mitigation is only attempted at that point then we're being left vulnerable for years to come.
    - scandinavian 7y ago

zrm 7y ago

> Since the assumption is that this class of exploit is known and patched, it might be less attractive for exploit makers to target. Given that, you can actually disable the mitigation to get the performance back without suffering a breach. This is an argument that anti-vaxxers use. And it works -- until enough people do it to compromise herd immunity. Then, suddenly, it doesn't work and you have a Very Bad Time.