Hacker News Reader

Comment by corty | Hacker News Reader

People regularly run untrusted Javascript in their browsers. Spectre is exploitable via Javascript as well. There are some mitigations, but those are generally just of the kind "make the timer API suck more" and the likes. Those mitigations don't really fully mitigate the problem and get more and more toothless with new variants of Spectre-like problems.

Spectre and the like needs to be dealt with on everything that isn't strictly an embedded fixed-code device.

View on HN

Is it possible to put these mitigations for Javascript only in the browser?

Some mitigations are implemented by browsers, but a lot of it has to happen at the OS level

Is it reliably exploitable from JS, or is it again a theoretical thing nobody has ever bothered to implement in practice? Is there a web page that would show me some of my kernel memory?

https://leaky.page/ will show you browser memory. Kernel memory is not vulnerable with browser sandboxing and current mitigations.

The two tests do work for me, but the actual leaking doesn't. No matter how I tweak the parameters, it fails with "error: too many wrong false negatives in leak test (> 20%)". I guess my CPU might just be too old ¯\_(ツ)_/¯

What browser/CPU? I only get "error: could not infer memory layout" on Firefox and Brave with a Zen 3 CPU

Vivaldi and i7-3615QM

https://leaky.page/

It's only theoretical until we discover that some state agency got it working three years ago and has been using it to quietly pwn activists since.

Firefox doesn't yet, but Chrome on desktop fully mitigates spectre using site isolation - every origin (including via embedded iframes, etc) runs in its own process.

> Chrome on desktop fully mitigates spectre using site isolation

Spectre and pals can literally jump between processes that it's no longer funny.

Realistically, only processes that are scheduled on sibling hyperthreads, and hyperthreading can be restricted to processes that have the same privilege level, which is done on ChromeOS. The amount of microarchetectural state that sticks around after a context switch is finite and whenever there's a new avenue found like this, usually easily fixed by ucode update and kernel fix.

> easily fixed by ucode update and kernel fix

Those microcode updates and kernel fixes are anything but easy. They are anything but lightweight. Context switching overhead is a huge contributor to lag and general inefficiency in interactive systems. Every kind of Spectre mitigation increases that overhead. Every further mitigation wrecks more of the performance advantages that caches have historically provided.

From a performance, power consumption and efficiency perspective, Spectre is a disaster. Mitigations just move the problem from a security and privacy one to an efficiency and performance one.

Ironically, Firefox has done a better job at following COOP/COEP: right now, it's completely possible in Chrome (until Chrome 91, which isn't stable yet) to read other sites' JS and images without their consent with Spectre.

Spectre is attack against that.

Fwiw, every time Chrome claims to fix a security problem their own way, somebody finds an exploit in it later.

Reply on news.ycombinator.com