Hacker News Reader

Comment by stefan_ | Hacker News Reader

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?

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

Disclosure: I work at Google and am involved in deploying some of these cross-origin resource restrictions internally.

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.

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.

Per site isolation =]

Which the (comparably) insecure likes of Firefox (unfortunately) does not have.

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

> "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.

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?

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.

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.

Reply on news.ycombinator.com