4 ms·

Why the mitigations are even on by default, if the problem doesn’t exist for dedicated single user environments? (desktops/laptops/dedicated server hardware wit

Why the mitigations are even on by default, if the problem doesn’t exist for dedicated single user environments? (desktops/laptops/dedicated server hardware with no code from other users running). Most desktops and laptops run a boatload of untrusted code in the form of JavaScript.

atemerev 7y ago
How about enabling mitigations in Javascript engines?
- danarmak 7y ago
  There aren't such mitigations to enable. There aren't even purely software kernel-level mitiations.
  - atemerev 7y ago
    > There aren't even purely software kernel-level mitiations. Some are there, otherwise they couldn't be disabled in Linux kernel for faster performance. Which means that they could be enabled on demand.
    - danarmak 7y ago
      Some are there, yes, but they're insufficient to provide security. You need both them, and the microcode changes, and to disable HT. I'm not sure what if anything the software changes do alone, they may mitigate some of the attacks, but not all of them.
- ggg2 7y ago
  why do you think you control that? apple tries, and even then people already managed to run code via pdf engines; on android it's at least more clear you have no control. You probably have apps in your phone runnig rigth now that ship with their own JS engine for advertising purposes. Do you expect them to have all the necessary safeguards?
- Asmod4n 7y ago
  Apple did just that in Safari on macOS.
  - msbarnett 7y ago
    Apple attempted to do that (I believe it was the Google security team’s MDS writeup that referred to it as a “Herculean effort” on the WebKit team’s part), but even they fell short. The position that all of the browser vendors have landed on at this point is that mitigating this class of attacks in the browser is simply not possible.
    - pdimitar 7y ago
      > ...but even they fell short. Can you please elaborate? Did these effort fail completely or is it that if you use your browser a certain way then you can never be protected? (Which implies that using it another way would be safe.)
      - msbarnett 7y ago
        per the v8 team, efforts to fully secure the JS JIT engine are simply infeasible against some Spectre class attacks: > Fourth, we found that effective mitigation of some variants of Spectre, particularly variant 4, to be simply infeasible in software, even after a heroic effort by our partners at Apple to combat the problem in their JIT compiler.
    - Asmod4n 7y ago
      You talking about the Update they released some days ago? Or those who are several months old? Apple released a new one for the newest vulnerability so they didn’t have to reduce the performance of macOS by ~30%.
      - msbarnett 7y ago
        I’m talking about the Chrome v8 team’s white paper on why they are giving up on trying to mitigate Spectre class attacks in software, which mentions, among other issues: > Fourth, we found that effective mitigation of some variants of Spectre, particularly variant 4, to be simply infeasible in software, even after a heroic effort by our partners at Apple to combat the problem in their JIT compiler. Apple released an update with some mitigations, but they are by no means perfect, and their message is that if you want to truly be safe, either don’t run JS, or disable hyperthreading.
jnordwick 7y ago
None of these have ben shown to work with a real-world exploit in JS. There is just too much noise going on. I'm getting so tired over how oveblown this is getting I was thinking of laying down a $1k bet if anybody will take me up on it, but I dont't think anybody would because it likely isnt possible. Most of the hype seems to be drive by some Intel gotcha hate.
- viraptor 7y ago
  Here's a JS speculative read example straight from the original meltdown paper turned into a PoC checker: https://terjanq.github.io/meltdown-checker/app.js https://terjanq.github.io/meltdown-checker/app.js I accept PayPal ;-) (Of course this depend on your definition of a "real world exploit", but this does show that you can cross boundaries of a type system.)
  - jnordwick 7y ago
    You know exactly what you are looking for at that exact address, without nothing else running and polluting the cache, and you are given an extended amount of time to attack. "you can cross boundaries of a type system" is not even close. In no world could this cod be used to gather useful data on a running system. You are literally just reading from an array you had setup.
    - geofft 7y ago
      It is well known in the academic literature that attacks "mitigated" by "there's too much noise, you'll have to try too many times, you can attack it in the lab but not on a real machine" are not mitigated at all. See for instance https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf . A practical case where you have an extended amount of time to attack are when you're an ad in a background tab of a website with interesting credentials.

atemerev 7y ago

How about enabling mitigations in Javascript engines?

danarmak 7y ago
There aren't such mitigations to enable. There aren't even purely software kernel-level mitiations.
- atemerev 7y ago
  > There aren't even purely software kernel-level mitiations. Some are there, otherwise they couldn't be disabled in Linux kernel for faster performance. Which means that they could be enabled on demand.
  - danarmak 7y ago
    Some are there, yes, but they're insufficient to provide security. You need both them, and the microcode changes, and to disable HT. I'm not sure what if anything the software changes do alone, they may mitigate some of the attacks, but not all of them.
ggg2 7y ago
why do you think you control that? apple tries, and even then people already managed to run code via pdf engines; on android it's at least more clear you have no control. You probably have apps in your phone runnig rigth now that ship with their own JS engine for advertising purposes. Do you expect them to have all the necessary safeguards?
Asmod4n 7y ago
Apple did just that in Safari on macOS.
- msbarnett 7y ago
  Apple attempted to do that (I believe it was the Google security team’s MDS writeup that referred to it as a “Herculean effort” on the WebKit team’s part), but even they fell short. The position that all of the browser vendors have landed on at this point is that mitigating this class of attacks in the browser is simply not possible.
  - pdimitar 7y ago
    > ...but even they fell short. Can you please elaborate? Did these effort fail completely or is it that if you use your browser a certain way then you can never be protected? (Which implies that using it another way would be safe.)
    - msbarnett 7y ago
      per the v8 team, efforts to fully secure the JS JIT engine are simply infeasible against some Spectre class attacks: > Fourth, we found that effective mitigation of some variants of Spectre, particularly variant 4, to be simply infeasible in software, even after a heroic effort by our partners at Apple to combat the problem in their JIT compiler.
  - Asmod4n 7y ago
    You talking about the Update they released some days ago? Or those who are several months old? Apple released a new one for the newest vulnerability so they didn’t have to reduce the performance of macOS by ~30%.
    - msbarnett 7y ago
      I’m talking about the Chrome v8 team’s white paper on why they are giving up on trying to mitigate Spectre class attacks in software, which mentions, among other issues: > Fourth, we found that effective mitigation of some variants of Spectre, particularly variant 4, to be simply infeasible in software, even after a heroic effort by our partners at Apple to combat the problem in their JIT compiler. Apple released an update with some mitigations, but they are by no means perfect, and their message is that if you want to truly be safe, either don’t run JS, or disable hyperthreading.

jnordwick 7y ago

None of these have ben shown to work with a real-world exploit in JS. There is just too much noise going on. I'm getting so tired over how oveblown this is getting I was thinking of laying down a $1k bet if anybody will take me up on it, but I dont't think anybody would because it likely isnt possible. Most of the hype seems to be drive by some Intel gotcha hate.

viraptor 7y ago
Here's a JS speculative read example straight from the original meltdown paper turned into a PoC checker: https://terjanq.github.io/meltdown-checker/app.js https://terjanq.github.io/meltdown-checker/app.js I accept PayPal ;-) (Of course this depend on your definition of a "real world exploit", but this does show that you can cross boundaries of a type system.)
- jnordwick 7y ago
  You know exactly what you are looking for at that exact address, without nothing else running and polluting the cache, and you are given an extended amount of time to attack. "you can cross boundaries of a type system" is not even close. In no world could this cod be used to gather useful data on a running system. You are literally just reading from an array you had setup.
  - geofft 7y ago
    It is well known in the academic literature that attacks "mitigated" by "there's too much noise, you'll have to try too many times, you can attack it in the lab but not on a real machine" are not mitigated at all. See for instance https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf . A practical case where you have an extended amount of time to attack are when you're an ad in a background tab of a website with interesting credentials.