4 ms·
Your web browser runs untrusted code. On a computer that never runs untrusted code you can do that.
by wolf550e 7y ago
Your web browser runs untrusted code. On a computer that never runs untrusted code you can do that.
- scandinavian 7y agoThere have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0). Sure, there is a chance that the Chrome/Firefox teams missed something, but there have been sighted no exploits since the release (of spectrev1) and the browser fixes. 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.
- dijit 7y agoWhat are you even talking about? the introduction to this problem came with a proof-of-concept _IN JAVASCRIPT_.[0] 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_and_meltdown_exploit_javascript_example/ https://www.reddit.com/r/javascript/comments/7ob6a2/spectre_...
- jotm 7y agoHa, I had the same thought, comparing this to antivaxxers. 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.
- scandinavian 7y agoFrom the comment in your link: > 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.
- dijit 7y agoThe browser mitigation’s only work with the kernel mitigation’s. Neither is working well without the other. And yes. I’m very well versed on this topic.
- scandinavian 7y ago>The browser mitigation’s only work with the kernel mitigation’s. That's just not true. The timer precision doesn't have anything to do with the kernel mitigations.
- dijit 7y agoThe timing precision thing by itself doesn't twarte anything, it just makes the attacks harder or take more time. 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.
- Grangar 7y agoBrowser 0-days still often run on user priviledges. The moment you get code-execution on a vulnerable Intel CPU that turns into hardware level access. And like the other commenter said, there are also JS implementations.
- deleted 7y ago[deleted]
- MiroF 7y ago> There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0). sure dude, sure
- scandinavian 7y agoChrome: CVE-2019-13720, CVE-2019-5786 Firefox: CVE-2019-11707/CVE-2019-11708 Your turn. Link the speculative execution 0days.
- MiroF 7y agoHere's an example of post-mitigation reading of protected memory using Javascript and Spectre https://alephsecurity.com/2018/06/26/spectre-browser-query-cache/ https://alephsecurity.com/2018/06/26/spectre-browser-query-c... 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.
- scandinavian 7y agoAs is said in the PoC, it does not bypass index masking and site-isolation. They read data already available to the code they are executing. They did show that the timer resolution mitigation is not 100% effective, which is well known and why it is not the only mitigation. 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?
- nullc 7y agoNot every computer runs a web browser. Of the hundreds of high performance cores I have, only a couple run a web browser. ... thought increasingly more of them are non-intel.