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

[phoronix]

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

Google has published their proof-of-concept code showing the practicality of Spectre exploits within modern web browsers' JavaScript engines. The code is out there and you can even try it for yourself on the leaky.page web-site...

https://www.phoronix.com/scan.php?page=news_item&px=Google-Leaky.Page-Spectre

[microcode]

Yup, that's terrifying. Don't run untrusted code in your browser even if you think you have a sandbox.

[willmore]

So we can finally ignore all of the people who've had their head in the sand saying "It's not a problem as there are no practical working exploits."?

[Xwaang]

I don't understand.
If I run:

[FONT=monospace][COLOR=#000000]grep . /sys/devices/system/cpu/vulnerabilities/* [/COLOR][/FONT]

I get the following result:

/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: VMX disabled
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, RSB filling
/sys/devices/system/cpu/vulnerabilities/srbds:Mitigation: Microcode
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Mitigation: Clear CPU buffers; SMT disabled

[FONT=monospace][/FONT]

So it seems that all should be mitigated, but the leaky.page works in any case.

[numacross]

I don't understand.

/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
[FONT=monospace][/FONT]

So it seems that all should be mitigated, but the leaky.page works in any case.

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

[remenic]

Yup, that's terrifying. Don't run untrusted code in your browser even if you think you have a sandbox.

Are you telling us not to visit any sites except for those hosted at 127.0.0.1 (and only after you've read the code!) ?

[microcode]

I don't understand.
If I run:

[FONT=monospace][COLOR=#000000]grep . /sys/devices/system/cpu/vulnerabilities/* [/COLOR][/FONT]

I get the following result:

/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: VMX disabled
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, RSB filling
/sys/devices/system/cpu/vulnerabilities/srbds:Mitigation: Microcode
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Mitigation: Clear CPU buffers; SMT disabled

[FONT=monospace][/FONT]

So it seems that all should be mitigated, but the leaky.page works in any case.

In this case, the target memory is in the same process, so you might have some protection from other processes with mitigations (though no guarantee of that).

[kozman]

I don't understand.
If I run:

[FONT=monospace][COLOR=#000000]grep . /sys/devices/system/cpu/vulnerabilities/* [/COLOR][/FONT]

I get the following result:

/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: VMX disabled
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, RSB filling
/sys/devices/system/cpu/vulnerabilities/srbds:Mitigation: Microcode
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Mitigation: Clear CPU buffers; SMT disabled

[FONT=monospace][/FONT]

So it seems that all should be mitigated, but the leaky.page works in any case.

Well, it might be a stretch to say this but one of two things must be true based on this leaky.page thing: 1) the above showing these are mitigated is bullshit in reality or 2) Google showing PoC *only* in Chrome is bullshit/smoke and mirrors. Why doesn't this repro in other browsers? it should if the PoC is coded correctly, no? Either way, I call bullshit on this PoC. Repro on other browsers or GTFO.

[kokoko3k]

Just another reason to keep js off by default

[coder]

Why doesn't this repro in other browsers? it should if the PoC is coded correctly, no? Either way, I call bullshit on this PoC. Repro on other browsers or GTFO.

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.