Applications, operating systems, and firmware all need to be updated to defeat Meltdown and protect against Spectre, two attacks that exploit features of high-performance processors to leak information and undermine system security. The computing industry has been scrambling to respond after news of the problem broke early a few days into the new year.
But that patching is proving problematic. The Meltdown protection is revealing bugs or otherwise undesirable behavior in various drivers, and Intel is currently recommending that people cease installing a microcode update it issued to help tackle the Spectre problem. This comes as researchers are digging into the papers describing the issues and getting closer to weaponizing the research to turn it into a practical attack. With the bad guys sure to be doing the same, real-world attacks using this research are sure to follow soon.
Back when initially releasing its Windows patch, Microsoft acknowledged incompatibilities with some anti-virus software. To receive the Meltdown and Spectre fixes, anti-virus software on Windows is required to create a special registry entry indicating that it’s compatible. Without this entry, not only are these patches blocked, but so too are all future Windows patches. Most anti-virus vendors should now have compatible versions of their products, but users with stale anti-virus software—expired trials or end-of-lifed products—are at this point much better off removing the third-party software entirely and using the built-in protection in Windows 8.1 and Windows 10.
While we understand the predicament this kind of incompatibility puts Microsoft in—anti-virus companies write software that is regularly broken by operating system-integrated security protections, and they petition regulators to punish Microsoft for this—we can’t help but feel that silently blocking all future patches is the wrong way to go. Bad anti-virus software is forcing Microsoft to leave customer systems at risk, and that’s not something that Microsoft or its customers should stand for.
However, anti-virus companies aren’t the only people to write ill-behaved drivers. ZDNet reports that a wide range of industrial systems is experiencing driver incompatibilities with the Meltdown fixes, with current guidance being to hold off on deploying the updates until the problems are resolved.
The Spectre updates are also proving problematic. Microsoft withdrew the patch for AMD systems last week after some machines were left unable to boot. The company has resumed distribution of the patch to most AMD systems, but some older machines are still being excluded.
Intel issued a microcode update that provided extra features that operating systems could use to protect against Spectre. But after reports of crashes, the company is now warning not to install it on systems with Haswell and Broadwell processors. If your motherboard or system vendor has an updated firmware with the new microcode, don’t install it, and if you’re using software such as VMware ESXi to update your microcode, VMware says you should revert to an earlier version.
This is all a mess. Some companies, such as cloud service providers, have no real option but to install all the updates, including the microcode updates, because their vulnerability is so great; their business is running untrusted third-party code. For the rest of us, there is urgency, but that needs to be balanced against reliability.
That urgency is growing with each day, however, particularly when it comes to the Meltdown attack. The research and proof-of-concept is currently missing certain pieces of information. The Meltdown technique described in the paper works (and researchers have already devised certain other similar techniques that build on the same principles), but it is subject to certain limitations. Specifically, it’s unable to leak information not in the processor’s level 1 cache, and it’s somewhat slow. This makes effective malicious use difficult, if not impossible.
However, these difficulties are not insurmountable. The researchers have a technique that can be used to retrieve any kernel data, and that technique (or some other technique, with the same capability) has been independently reinvented by at least three other people. This research still seems to be some way short of the claimed 500kB/s claimed in the paper, but it’s clear that researchers are getting closer to turning Meltdown into a truly useful attack.
What the good guys can do, so too can the bad guys; it can’t be long now before real-world attacks use these techniques to locate sensitive data or break out of sandboxes. The race is truly on, and it’s by no means guaranteed that the buggy drivers and microcode will be fixed before malicious hackers start exploiting Meltdown.