Google Publishes "Leaky.Page" Showing Spectre In Action Within Web Browsers

[gQuigs]

Does Firefox not expose the same high precision timers? I tried:
Brave (Chromium based) and it worked instantly
Firefox - the exploit didn't work.

I know when spectrev1 was first released they made them less predictable - https://developer.mozilla.org/en-US/...erformance/now

[Xwaang]

The one I cropped means that the mitigation is disabled by default and needs to be enabled by using prctl() or seccomp(). Chromium should be enabling it for its processes by default tho...

You are right.
Adding

spec_store_bypass_disable=on

to the kernel command solves the issue and the leaky.page does not leak anything anymore!

[SofS]

Does Firefox not expose the same high precision timers? I tried:
Brave (Chromium based) and it worked instantly
Firefox - the exploit didn't work.

I know when spectrev1 was first released they made them less predictable - https://developer.mozilla.org/en-US/...erformance/now

Reducing the precision of time measurements was one of the first mitigations Mozilla implemented, see:

https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/

[Pajn]

Does Firefox not expose the same high precision timers? I tried:
Brave (Chromium based) and it worked instantly
Firefox - the exploit didn't work.

I know when spectrev1 was first released they made them less predictable - https://developer.mozilla.org/en-US/...erformance/now

Look at the first timing test in Firefox and Chrome where you can clearly see that the Firefox result is artificially limited to 1 ms. How did you think Chrome always manages to keep their top position in JS performance benchmarks?

The tragic thing is that for real browsing performance it doesn't matter which can be seen in more realistic benchmarks, meaning that Chrome exposes your RAM to the world for no reason.

[numacross]

You are right.
Adding

spec_store_bypass_disable=on

to the kernel command solves the issue and the leaky.page does not leak anything anymore!

And the performance penalty for it is?

[mppix]

Someone should tag this post so we can finally put the argument "I want all the performance and it is fine because I run only trusted code" to rest.

However, I'm surprised that google among all possible actors is demoing this.

[uid313]

You can use the NoScript Security Suite extension for Firefox, then you can chose to disable all JavaScript except the ones you whitelist.

It would be great if Snap or Flatpak could be used to improve the security of web browsers. Firefox is available as a Flatpak image.

[numacross]

However, I'm surprised that google among all possible actors is demoing this.

Why? Their Project Zero was involved in discovering both Spectre and Meltdown. They do a lot of this kind of research.

[martinus]

Speculative and out-of-order execution have been a major contributor to CPU performance in the last few decades. It is not surprising they allow for a certain amount of out-of-band information gathering when having full access to a machine.
The real scandal is a different one: that we allow the execution of turing-complete software from arbitrary web sites, sandboxed or not. That is the practice that needs to stop. But I do not assume humanity will come to their senses any time soon.

[stormcrow]

It could be that the exploit needs to be tuned to the particular JIT engine, in which case they certainly could do it but haven't invested the time.

That's what they said in the article. It's tuned to work on Chrome and Intel CPUs. But they got it to also work on Chrome with Apple's M1 CPU. It takes some effort to tune it to other engines and CPUS and they didn't try.

Long past time to stop advocating disabling mitigations just to get a couple of extra seconds of performance out of your web browsing. This isn't the only fully working Spectre malware in the wild. It's turned up on samples submitted to VirusTotal as well.