5 ms·

So... what is the worse case scenario if you decide to disable these mitigations? What precausions one can take to be relatively safe while turning these off?

ekimekim 7y ago
In general, these kinds of attacks are cross-process information leaks and sandbox escapes. The attack vector is untrusted code running on your system, of which the by far most common and most potentially malicious is javascript when you use a web browser. So the worst case scenario? You visit a website with some attacker-controlled javascript, and it successfully picks up information leaks from your password manager allowing it to obtain all your passwords. I'm not sure how realistic that attack is. I know that for some of these vulnerabilities attacks from javascript were shown to be possible, but I'm not sure what the target information was in that case.
- specialist 7y ago
  Are there ways to prevent data from being in the cache? I know almost nothing about computer security. I ask because ages ago, I added copyright protection to some products (under protest). Though encrypted on disk, once loaded, all our code and key phrases were "plaintext" in memory, easy to read. Hackers would post cracked versions of our releases within 24 hours. The whole effort seemed pointless. My takeaway was if you had physical access, you have everything. But maybe things have improved.
  - ekimekim 7y ago
    If you have physical access, you have everything (given sufficient time and effort). This will always be true, though dedicated security hardware (TPMs, etc) might drive up that time and effort requirement to get at their contents. The access provided by these attacks is a far cry from physical access. There are plenty of things that can be done to mitigate them (removing data from the cache, for example). Of course, this entire post is about how to disable those mitigations, as they almost always come with a performance penalty.
  - Shikadi 7y ago
    In memory data like that is always accessible by someone who wants it bad enough (with a physical device and a clean install), one can run Windows in a debugger like environment and view all of system memory. I think that's why most DRM is web authentication based
jeroenhd 7y ago
If/when someone finds a way around the timer patch in your web browser (or if your browser doesn't have the patch yet for some weird reason), a website running javascript for long enough can extract kernel secrets and AES keys, a password manager's entire database, any application's authentication token and pretty much anything else in memory. Executing such an attack is difficult and unreliable, but in my opinion this also means that casting a wide net might be worth it for the attacker instead of only using the exploit kit to target specific computers. If you run any software in a virtual machine or docker app, this boundary is easily crossed. If you run any application whose supply chain might be attacked (for example, one of the million javascript files in an electron app), such an app can get root on your system through any sandboxing and virtualisation. Edit: obviously, this is a worst case scenario.
- vbezhenar 7y ago
  Majority of users won't turn those protections off as they don't even know about them. So one can't really cast a wide net.
  - bashinator 7y ago
    I think they meant casting a wide net in search of the small percentage of machines where the mitigation’s are turned off. An 0.01% success rate is okay if you hit ten million systems.
- snthd 7y ago
  Is it feisable to make privilege escalation of this sort impossible, by shifting cryptographic verification to dedicated hardware?
  - waz0wski 7y ago
    Intel hardware has SGX, the concept of a secure enclave for sensitive data ... which is also vulnerable to the same class of speculative execution exploits on hardware generations prior to Cascade Lake Specifically it was a trio of vulnerabilities colloquially known as 'Foreshadow / L1TF': CVE-2018-3615, CVE-2018-3620, and CVE-2018-3646, https://en.wikipedia.org/wiki/Foreshadow_(security_vulnerability) https://en.wikipedia.org/wiki/Foreshadow_(security_vulnerabi...
rwmj 7y ago
I have a c.2016 Intel development machine. I never log in at the console or use any GUI, it runs command line only Fedora Linux and apart from that it only ever runs code that I myself have written. Because I use it for compiling and testing I need it to run as fast as possible. Over the past few years it has really slowed down. I got some (not nearly all) of the performance back by using some of the command line options shown here. I'm going to try the whole command line later today and do some actual before and after testing. But IMO this is the kind of situation where turning off the mitigations makes sense.
- imhoguy 7y ago
  Also check SSD wear level if you use one.
  - eikenberry 7y ago
    How do you check that?
    - imhoguy 7y ago
      On Linux one does with `smartmontools` usually. Indicator depends on the device vendor. https://unix.stackexchange.com/questions/106678/how-to-check-the-life-left-in-ssd-or-the-mediums-wear-level https://unix.stackexchange.com/questions/106678/how-to-check...

ekimekim 7y ago

In general, these kinds of attacks are cross-process information leaks and sandbox escapes. The attack vector is untrusted code running on your system, of which the by far most common and most potentially malicious is javascript when you use a web browser. So the worst case scenario? You visit a website with some attacker-controlled javascript, and it successfully picks up information leaks from your password manager allowing it to obtain all your passwords. I'm not sure how realistic that attack is. I know that for some of these vulnerabilities attacks from javascript were shown to be possible, but I'm not sure what the target information was in that case.

specialist 7y ago
Are there ways to prevent data from being in the cache? I know almost nothing about computer security. I ask because ages ago, I added copyright protection to some products (under protest). Though encrypted on disk, once loaded, all our code and key phrases were "plaintext" in memory, easy to read. Hackers would post cracked versions of our releases within 24 hours. The whole effort seemed pointless. My takeaway was if you had physical access, you have everything. But maybe things have improved.
- ekimekim 7y ago
  If you have physical access, you have everything (given sufficient time and effort). This will always be true, though dedicated security hardware (TPMs, etc) might drive up that time and effort requirement to get at their contents. The access provided by these attacks is a far cry from physical access. There are plenty of things that can be done to mitigate them (removing data from the cache, for example). Of course, this entire post is about how to disable those mitigations, as they almost always come with a performance penalty.
- Shikadi 7y ago
  In memory data like that is always accessible by someone who wants it bad enough (with a physical device and a clean install), one can run Windows in a debugger like environment and view all of system memory. I think that's why most DRM is web authentication based

jeroenhd 7y ago

If/when someone finds a way around the timer patch in your web browser (or if your browser doesn't have the patch yet for some weird reason), a website running javascript for long enough can extract kernel secrets and AES keys, a password manager's entire database, any application's authentication token and pretty much anything else in memory. Executing such an attack is difficult and unreliable, but in my opinion this also means that casting a wide net might be worth it for the attacker instead of only using the exploit kit to target specific computers. If you run any software in a virtual machine or docker app, this boundary is easily crossed. If you run any application whose supply chain might be attacked (for example, one of the million javascript files in an electron app), such an app can get root on your system through any sandboxing and virtualisation. Edit: obviously, this is a worst case scenario.

vbezhenar 7y ago
Majority of users won't turn those protections off as they don't even know about them. So one can't really cast a wide net.
- bashinator 7y ago
  I think they meant casting a wide net in search of the small percentage of machines where the mitigation’s are turned off. An 0.01% success rate is okay if you hit ten million systems.
snthd 7y ago
Is it feisable to make privilege escalation of this sort impossible, by shifting cryptographic verification to dedicated hardware?
- waz0wski 7y ago
  Intel hardware has SGX, the concept of a secure enclave for sensitive data ... which is also vulnerable to the same class of speculative execution exploits on hardware generations prior to Cascade Lake Specifically it was a trio of vulnerabilities colloquially known as 'Foreshadow / L1TF': CVE-2018-3615, CVE-2018-3620, and CVE-2018-3646, https://en.wikipedia.org/wiki/Foreshadow_(security_vulnerability) https://en.wikipedia.org/wiki/Foreshadow_(security_vulnerabi...

rwmj 7y ago

I have a c.2016 Intel development machine. I never log in at the console or use any GUI, it runs command line only Fedora Linux and apart from that it only ever runs code that I myself have written. Because I use it for compiling and testing I need it to run as fast as possible. Over the past few years it has really slowed down. I got some (not nearly all) of the performance back by using some of the command line options shown here. I'm going to try the whole command line later today and do some actual before and after testing. But IMO this is the kind of situation where turning off the mitigations makes sense.

imhoguy 7y ago
Also check SSD wear level if you use one.
- eikenberry 7y ago
  How do you check that?
  - imhoguy 7y ago
    On Linux one does with `smartmontools` usually. Indicator depends on the device vendor. https://unix.stackexchange.com/questions/106678/how-to-check-the-life-left-in-ssd-or-the-mediums-wear-level https://unix.stackexchange.com/questions/106678/how-to-check...