It's not a crazy threat model to have on a personal PC, the risk is so very minimal. If your threat model is that strict you shouldn't be running JS anyway.
Session keys, private keys, passwords and all other kinds of access tokens that your system is using, it's the next worst thing from remote code execution.
Your browser runs so much untrusted code that it's really unreasonable, and yes, we should definitely be pushing back hard on this. But it's probably the most stupid thing you can do to disable these mitigations because they're not just theoretical, they're real, they're here and everyone knows about them.
This is like anti-vaxx philosophy. "the risk is low"; well, maybe the risk is low because of herd immunity, it's not feasible to run these attacks as they'll be obvious to those who have the mitigations in place (100% CPU), but if there's a 0.00000001% return then it becomes profitable to exploit, just like mail spam.
Do not fucking turn off these mitigations on desktop computers, they are too complex and run untrusted code all the time. Unless you can work without javascript and I doubt you can because the web today is basically unusable without it.
If you have a database which is only accessible internally, you can disable the mitigations, because those things are hit hardest by the mitigations and do not run untrusted code.
But really, your desktop is running untrusted code _a lot_. Please do not do this, not only for your own sake but for everyones sake. Don't make it profitable for malicious agents to run these attacks.
[0]: https://www.reddit.com/r/javascript/comments/7ob6a2/spectre_...
The downsides are of course, infinitely lower (stolen password vs disability or death), but yeah the similarity is there.
We've yet to see a real world attack using any of these, however.
> It's missing the entire actual implementation of the Spectre attack, which requires analysis of read times to see if you're hitting the processor cache or not.
"analysis of read times" is what the browsers "fixed" to mitigate the attacks (and site isolation later). Again, there has been no working attacks on updated browsers.
Please feel free to link an example of one though, I will gladly admit I'm wrong. You just seem to frankly have no idea how the exploits actually work though (did you actually read the code in the reddit post?), so I suspect that this conversation will be a waste of time.
That's just not true. The timer precision doesn't have anything to do with the kernel mitigations.
The browser vendors themselves said this; and it's not a permanent solution as tech such as Stadia and WebVR rely on high precision timers.
But, whatever man, I'm telling you that it's stupid and you want to bury your head in the sand.
You just make these attacks more likely; I'm not going to be impacted except for a few trillion CPU cycles of idiots trying to exploit me.
You're the one who puts their entire digital life on the line by eking out 5% performance.
Oh, so it just takes more time, so you have knowledge of an exploit? Fine, show me any PoC or similar bypassing the lower accuracy and site isolation.
You are such a big part of the problem with how this whole class of exploits have been handled. No technical knowledge, just spewing stuff like "You're the one who puts their entire digital life on the line", when we there is no indication that anything like that can transpire.
Please stop spreading misinformation.
This is not misinformation, _you_ are spreading "certainty" of safety surrounding a dangerous idea.
https://spectreattack.com/spectre.pdf
Even if I was wrong, and very wrong, why the hell would you choose to be less safe? this whole thread chain is absolutely baffling. Buy an AMD CPU or leave the mitigations on. Everything else is needlessly opening yourself up.
Yeah, which was why SharedArrayBuffer was disabled when spectrev1 was released. It is still disabled in Chrome if site-isolation is disabled and it's still disabled in firefox.
You should really know all this if you are so very well versed in the subject.
>Even if I was wrong, and very wrong, why the hell would you choose to be less safe? this whole thread chain is absolutely baffling. Buy an AMD CPU or leave the mitigations on. Everything else is needlessly opening yourself up.
I don't run without migrations. I commented on the original parent comments threat model and that I think it's perfectly logical. And I maintain this, if your threat model is so strict, that you are afraid of speculative execution vulnerabilities hitting you through javascript, you should not run JS at all, as regular js 0days have hit while no actual speculative execution browser exploits have hit.
That’s a very wide attack scope.
You can't use the speculative execution vulnerabilities to just read all system memory using a javascript exploit. Like the exploit that is the topic of this post can't be used in a browser at all, as you are limited to what the JIT executes, you can't just execute TSX instructions in a browser.
You might be thinking of when you have native code execution.
> We leak a string from another process using Javascript and WebAssembly in the SpiderMonkey engine.
They leak in flight data, using a detached spidermonkey engine, patched to make performance.now() return rdtscp at a rate of 1B/s while the victim application is spamming a load string instruction as fast as possible.
This does not allow:
>any ad network can access any and all memory on your desktop
This allows any ad-network to access random bits on the cache line. If the timing mitigation didn't already fix this, it seems impossible to me to get anything useful from it, the precision and bitrate is just too low (which is why the exploit just spams load instructions in a while 1 loop).
>and the RIDL exploits don't require special instructions.
Weird, in the new addendum it says it uses TSX, and in the PoC it uses XBEGIN. Must be a mistake.
And like the other commenter said, there are also JS implementations.
sure dude, sure
Your turn. Link the speculative execution 0days.
I think it's just silly that you would rely on browser mitigations like disabling high precision timers when that's obviously just a hack.
That's not a speculative execution browser 0day, as it doesn't work in updated browsers and it never has (or I guess it works if you want to leak data you could just console.log). Could you post an actual 0day instead?