These attacks work fine in the browser, as researchers continue to show. They allow complete bypass of any native app sandboxing layers. Surely you don't run everything on your box as root all the time.
Can you link to a hosted example of one of these. That would convince people nicely. Someone linked to one in a similar discussion yesterday but it didn't work anymore in currently patched browsers.
Meh. It doesn't require Javascript for your computer to run logic described by others. Browsers are such complex machines that it wouldn't surprise me if you could for example craft a malicious SVG that would bypass that, or a turing-complete CSS file that triggers a vulnerability...
By the way, does NoScript actually block in-SVG javascript?
Sure, but we all take risks every day. If you're worring about turning-complete CSS files exploiting Spectre and Meltdown then you probably don't leave the house much.
We know that attackers have reason to exploit literally all compute resources they can find a way to access. This is more like worrying about leaving the house during an epidemic of exploding ebola-infected pigeons — if you can do something about it, you should.
Attackers also have to consider cost/benefit analysis when evaluating methods of attack. Claims that "CSS is Turing complete" require a user to act as a "crank" [0], so there are lower-hanging fruit out there than trying to program complicated logic which can utilize the Meltdown / Spectre exploits in CSS.
Yes and no. It is possible to exploit Meltdown / Spectre via Javascript. From [0]:
> This can happen when one has opened the other using window.open, or <a href="..." target="_blank">, or iframes. If a website contains user-specific data, there is a chance that another site could use these new vulnerabilities to read that user data.
Most browsers have pushed patches which eliminate known mechanisms of leveraging the exploit, but the pathway cannot be completely mitigated by browser patches, I believe.
Given that most consumers run JavaScript unconditionally, yes. Browser vendors have basically declared Spectre/Meltdown/MDS unmitigatable at the browser level.
> Second, the increasingly complicated mitigations that we designed and implemented carried significant complexity, which is technical debt and might actually increase the attack surface, and performance overheads. Third, testing and maintaining mitigations for microarchitectural leaks is even trickier than designing gadgets themselves, since it’s hard to be sure the mitigations continue working as designed. At least once, important mitigations were effectively undone by later compiler optimizations. Fourth, we found that effective mitigation of some variants of Spectre, particularly variant 4, to be simply infeasible in software, even after a heroic effort by our partners at Apple to combat the problem in their JIT compiler.
> Our research reached the conclusion that, in principle, untrusted code can read a process’s entire address space using Spectre and side channels. Software mitigations reduce the effectiveness of many potential gadgets, but are not efficient or comprehensive.
The “some variants” include MDS, which the author was aware of but which were not at the time of publication out of embargo.
But they do not claim that hardware mitigations are necessary. They claim that they need to change browser architecture a little bit:
> The only effective mitigation is to move sensitive data out of the process’s address space. Thankfully, Chrome already had an effort underway for many years to separate sites into different processes to reduce the attack surface due to conventional vulnerabilities. This investment paid off, and we productionized and deployed site isolation for as many platforms as possible by May 2018.
So with improved browsers it's still unclear why ordinary users need those performance-eating mitigations, when browser vendors managed to solve that problem themselves.
> But they do not claim that hardware mitigations are necessary. They claim that they need to change browser architecture a little bit
For Spectre, that’s enough; for Spectre-class Intel permission exploit vectors (aka, Meltdown, Fallout, ZombieLoad, RIDL, Store to Leak Forwarding and other MDS vulnerabilities) all of the same infeasability of browser mitigations apply but data also leaks across process boundaries, so process isolation does jack shit to protect you without lower level mitigations.
There’s nothing whatsoever browsers can do to prevent this. Process memory read isolation effectively doesn’t exist in the presence of unpatched Intel MDS vulnerabilities.
> So with improved browsers it's still unclear why ordinary users need those performance-eating mitigations, when browser vendors managed to solve that problem themselves.
The unclarity is only in your misunderstanding of the relationship of MDS vulnerabilities on Intel to Spectre vulnerabilities in general.
These vulnerabilities can jump process address space boundaries. It's a lot harder but can be done, look at the original Spectre paper: https://spectreattack.com/spectre.pdf
These attacks work fine in the browser, as researchers continue to show. They allow complete bypass of any native app sandboxing layers. Surely you don't run everything on your box as root all the time.