Even when people started speculating (ha!) that speculative execution could be problematic it took years before they managed to exploit it.
Are they really? I don't have an extremely deep understanding of Intel's implementation of x86 ISA, but I do know enough to say that so far we've been able to effectively mitigate almost all of these attacks with existing instructions available on the Intel CPUs. That doesn't mean that they are still not open to other variants of these attacks - but at some point you have to assume diminishing returns. Spectre is still very difficult to exploit, for example.
Perhaps this has little to do with Intel and more to do with software authors cutting corners? LFENCE and SFENCE are reasonably well documented, after all...
https://www.theregister.co.uk/2007/06/28/core_2_duo_errata/
The scariest part is that many of the best security minds work for various intelligence agencies. They very likely have known about such things for a very long time.
Meltdown strikes me as an almost perfect vulnerability. It affects almost everyone. It is undetectable until exploited and once exploited, it immediately goes away until the next time. It's easy to keep secret. Most importantly, it's a one-way vulnerability. Keep your secure systems from running untrusted code and there's zero risk. Since this is standard protocol anyway for those systems, you don't have the risk of someone running across a code patch somewhere.
The only potential downside is that the juiciest targets also aren't running untrusted code (though most foreign affairs workers probably run untrusted code). The big point of interest here is information symmetry. In most cases, giving others secret information is bad. In this case, both the best and worse case situations work out well for the USA. If nobody else knows, they get free info. If everyone else does know, then everyone gets perfect information about everything. This favors the most powerful country. They can eliminate the unknowns (the only real danger). In contrast, knowing you are going to be crushed does nothing if you can't hide your own hand either. So, the best case is very good and the worst case is still acceptable.
Most consumer wouldn't care about this anyway and the risk was overblown.
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.
By the way, does NoScript actually block in-SVG javascript?
> 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.
[0] https://developers.google.com/web/updates/2018/02/meltdown-s...
> 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.
> 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.
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.