A couple of serious hardware vulnerabilities got disclosed recently, following rumors regarding them coming up, with fancy names that the vulnerabilities get these days. With logos, too. Less fancy names are CVE-2017-5715 and CVE-2017-5753 (for Spectre), and CVE-2017-5754 (for Meltdown).
The vulnerabilities were known for a while, but weren’t disclosed publically, though were reported to Intel, AMD, and ARM on 2017-06-01, as stated in the Project Zero blog post. And Intel’s CEO has sold his stock just before the publication. That would be a good laugh if it didn’t mean that most of the computers are screwed by more than just the backdoors Intel puts into their CPUs, or the occasional vulnerabilities in those backdoors.
The modern processors are pretty sophisticated, incorporating plenty of optimizations such as speculative execution. The attacks are also interesting, so you may want to read the papers (meltdown.pdf, spectre.pdf), but briefly – both allow any process on any system and on a lot of the used (i.e., modern, from the current millennium) hardware to read all the data from memory. Commonly used kinds of virtualization don’t help, and even JavaScript in a web browser was successfully used to exploit it, as the Spectre paper claims. Meltdown—which can be mitigated with a kernel patch and only works on Intel and newer ARM processors—allows to read memory at a decent speed, while Spectre seems to be considerably slower, yet harder to mitigate. There’s a PoC (apparently just copied from the paper though), too.
In order to partially mitigate it, one could update all their systems and disable JavaScript execution (e.g., with noscript or uMatrix, which are useful even without vulnerabilities like these). But with Spectre around, processes may still be able to see all the memory contents, even across virtual machines (“VPS”, “cloud”, or whatever they are called today). Consequently, the data on services that use such virtual machines got compromised – likely leading to a wave of data breaches.
There’s not much else to do about it now, short of moving everything private to dedicated machines (like RPis or low-end servers if you don’t need a lot of performance) and actually reviewing the software you use. On the bright side, there is a logo to use as a sticker for your vulnerable machines. We could also wait for fixes in newer CPUs; the Intel CEO would probably buy their cheap shares back once that will be about to get announced.
ARM actually published “Speculative Barrier” in an hour after the papers were compiled (see also: Arm Processor Security Update); a somewhat similar (and similarly hard-to-apply-to-everything) mitigation technique, Retpoline, was presented by Google, not dated; IBRS patch series were presented by Intel on the following day. Kernel developers were also busy patching things since, but it’s somewhat puzzling why the patches were delayed, and why OS vendors weren’t given a chance to prepare patches before the public disclosure (though a word on the streets is that distribution maintainers were given a couple of months, but for some reason didn’t manage to incorporate patched kernels in that time). Although strange and somewhat related (yet not all that helpful) LPTI patching was going on since before the disclosure, and there’s a bit more of the story: “How an industry-breaking bug stayed secret for seven months — and then leaked out”.
Just a few days after the disclosure, some npm packages disappeared from repositories, providing a good opportunity to infiltrate systems and exploit the newly known vulnerabilities. To make things even more fun, with the hurried patches Microsoft has bricked some CPUs, and Ubuntu has followed it. Another word on the street is that Intel patches also turned out to be buggy, and now they advice the customers to hold off with the updates, though intel.com suggests that “[e]nd-users should continue to apply updates”. And unlike Linux, MS, and Canonical developers, they knew about it since June – though apparently not the whole story, and didn’t share it with those departments that were able to work on it.
Weeks after the disclosure, not all the common CPUs got microcode updates, and not all the major GNU/Linux distributions have incorporated all the available kernel patches. Linus shouts at Intel folks who try to provide mitigation patches, calling those “COMPLETE AND UTTER GARBAGE”.
FreeBSD.org maintains a table of architectures by vulnerability.
See also: