4 ms·

Really? Their proposed mitigations are various Cross Origin Resource restrictions? That's the equivalent of saying "just don't run bad JS code". It's not worka

Really? Their proposed mitigations are various Cross Origin Resource restrictions? That's the equivalent of saying "just don't run bad JS code". It's not workable. Have they given up?

ddworken 6y ago
See this[1] paper for more information. I think from the browser POV it is more about admitting that it just isn't possible to reliably mitigate Spectre and instead focusing on what can be done at the browser level. And at the browser level, it is possible to ensure that sensitive resources don't end up in processes running attacker JS. Of course this could be fixed at the CPU level, but realistically very few people want that since that would drastically slow down modern CPUs which rely on speculative execution. [1]: https://arxiv.org/pdf/1902.05178.pdf https://arxiv.org/pdf/1902.05178.pdf Disclosure: I work at Google and am involved in deploying some of these cross-origin resource restrictions internally.
- the8472 6y ago
  But it's still going to help exploits against the browser, isn't it? Letting code poke around until it finds addresses it needs or something like that.
  - ddworken 6y ago
    As I understand it (though I don't work directly on Chrome), a key part of Chrome's threat model is that a compromised renderer process (where there is one renderer process per site) has limited security impact. So being safe against Spectre (which gives a read primitive in the renderer process) is just a subset of being safe against a compromised renderer process.
    - 177tcca 6y ago
      Per site isolation =] Which the (comparably) insecure likes of Firefox (unfortunately) does not have.
      - ddworken 6y ago
        Not yet! But soon. :) See Project Fission [1]. Currently if you're using Beta or Nightly you can toggle it on and I believe it is getting very close to being ready to ship. [1]: https://wiki.mozilla.org/Project_Fission https://wiki.mozilla.org/Project_Fission
Shared404 6y ago
> "just don't run bad JS code". It's not workable. A little NoScript goes a long way. At least that way you can pick what you want to run.
- stefan_ 6y ago
  Oh yes, if you ask me, throw this JIT shit out. Whats the spectre rate like if you need to do it through slow as molasses bytecode? 1b/minute?
  - monocasa 6y ago
    It's not the JIT that's the issue, but a deeper problem. It's untrusted instruction streams which.you can get from just untrusted data too. Netspectre was able to dump kernel memory just from untrusted received network packets, no jit required.
- xiphias2 6y ago
  It seems to me like timers and multi-threading make these things possible, so why couldn't the web site ask for access for those resources from the user? Most web sites don't need these. HN should work without reading timers at all for example.

Really? Their proposed mitigations are various Cross Origin Resource restrictions? That's the equivalent of saying "just don't run bad JS code". It's not workable. Have they given up?

ddworken 6y ago

See this[1] paper for more information. I think from the browser POV it is more about admitting that it just isn't possible to reliably mitigate Spectre and instead focusing on what can be done at the browser level. And at the browser level, it is possible to ensure that sensitive resources don't end up in processes running attacker JS. Of course this could be fixed at the CPU level, but realistically very few people want that since that would drastically slow down modern CPUs which rely on speculative execution. [1]: https://arxiv.org/pdf/1902.05178.pdf https://arxiv.org/pdf/1902.05178.pdf Disclosure: I work at Google and am involved in deploying some of these cross-origin resource restrictions internally.

the8472 6y ago
But it's still going to help exploits against the browser, isn't it? Letting code poke around until it finds addresses it needs or something like that.
- ddworken 6y ago
  As I understand it (though I don't work directly on Chrome), a key part of Chrome's threat model is that a compromised renderer process (where there is one renderer process per site) has limited security impact. So being safe against Spectre (which gives a read primitive in the renderer process) is just a subset of being safe against a compromised renderer process.
  - 177tcca 6y ago
    Per site isolation =] Which the (comparably) insecure likes of Firefox (unfortunately) does not have.
    - ddworken 6y ago
      Not yet! But soon. :) See Project Fission [1]. Currently if you're using Beta or Nightly you can toggle it on and I believe it is getting very close to being ready to ship. [1]: https://wiki.mozilla.org/Project_Fission https://wiki.mozilla.org/Project_Fission

Shared404 6y ago

> "just don't run bad JS code". It's not workable. A little NoScript goes a long way. At least that way you can pick what you want to run.

stefan_ 6y ago
Oh yes, if you ask me, throw this JIT shit out. Whats the spectre rate like if you need to do it through slow as molasses bytecode? 1b/minute?
- monocasa 6y ago
  It's not the JIT that's the issue, but a deeper problem. It's untrusted instruction streams which.you can get from just untrusted data too. Netspectre was able to dump kernel memory just from untrusted received network packets, no jit required.
xiphias2 6y ago
It seems to me like timers and multi-threading make these things possible, so why couldn't the web site ask for access for those resources from the user? Most web sites don't need these. HN should work without reading timers at all for example.