In the first week of this new year, I – along with almost every member of the technology writing community – wrote about two major processor security flaws called Meltdown and Spectre, which affect a huge proportion of the computers and devices that are in use today all over the world. Between the two, everyone from home users to cloud data center managers and including all those company IT professionals who make up the primary readership of this blog are still contending with this newly disclosed threat and scrambling to ensure that their machines are protected against it.

It’s been a month now since Spectre and Meltdown hit the headlines after they were disclosed by Google Project Zero on January 3, and more has been learned about these vulnerabilities, as well as steps taken to defend against them, during that time. Here is some additional information to help you understand the threat, the mitigations and fixes, and some of the unintended consequences of the patches that have been released.

Understanding the threat

A brief recap of what it is we’re dealing with. Meltdown and Spectre are two separate vulnerabilities that both affect computer processors (and that includes many of the small, specialized computers that run various devices).  They were discovered by four separate teams of researchers, who reported them to the processor vendors months before the public was made aware of the problem. The scary part is that the vulnerabilities have existed for decades.

Meltdown impacts Intel processors and enables attackers to bypass the protections that normally prevent applications from accessing information that resides in locations in memory, so that they can access and capture sensitive information such as passwords, credit card numbers, and personal data in the system memory.  It relies on the way out-of-order execution is handled, and bypasses memory protection by exploiting a privilege escalation vulnerability that is specific to Intel processors.

Spectre is a “speculative execution” vulnerability that affects Intel, AMD, and ARM processors and can make applications disclose data that is supposed to be in protected kernel memory. For the nitty gritty details on how Spectre works, see this paper titled Spectre Attacks: Exploiting Speculative Execution. A primary attack vector for Spectre – which is the more widely applicable of the two but is also the harder vulnerability to exploit – is through JavaScript running on a web browser.  

At the time of my earlier writing, there had been no reported exploits of the vulnerabilities “in the wild.” Of course, we all knew that was sure to change soon after the story broke. And in fact, as January came to a close a German security company, AV-Test Institute, has found a number of malware samples that they say appear to exploit (or attempt to exploit) the Meltdown and Spectre vulnerabilities. They appear to be based on proof-of-concept attacks that were published online.

To patch or not

As serious as the exploitation of Meltdown and Spectre could be – exposing all types of sensitive information – and with malware now being discovered that take advantage of the vulnerabilities, you would think the decision to apply patches that were quickly made available by hardware and software vendors would be an easy one.

However, although the companies are to be commended for rushing to address the threat as soon as possible after disclosure, an unfortunate and not uncommon side effect of security updates that are created and released quickly is that they may have a negative impact on the systems they’re designed to protect, ranging anywhere from annoying but not debilitating performance slowdowns to rendering computers unbootable.

Soon after patches for Meltdown and Spectre came out, reports started to come in that those patches were causing error messages, logon problems, and random reboots on some systems. A less serious but nevertheless troublesome complication experienced by some who installed the patches was a significant increase in processor usage and resultant performance degradation, although some also reported that this seemed to level off later.

Intel ended up recommending that OEMs, cloud service providers, system manufacturers, software vendors and end users stop deployment of current versions, and Microsoft suspended its updates for AMD systems after blue screen crashes occurred during the boot process on systems with some AMD chipsets. On January 18, Microsoft 4 announced it would resume rolling out patches for AMD devices running Windows 7 SP1 and Windows Server 2008 R2 SP1, Windows 8.1 and Windows Server 2012 R2, and Windows 10, version 1709. 

On January 29, Microsoft released an emergency out-of-band patch for Windows that disabled Intel’s fix for the Spectre 2 variant, because it was causing system instability that could lead to data loss or corruption on some systems, which could be much more serious than the unexpected reboots. Around the same time, HP and Dell had stopped deploying BIOS updates that contained the Intel fix. Microsoft’s cumulative update for the Windows 10 Fall Creators Update (version 1709) that was released January 31 updates Windows 10 to build 16299.214 and resolves the issues in KB4056892 that was pushed to customers in early January to help fix the Spectre and Meltdown exploits.

The patching dilemma was further complicated by the many different entities that distributed them and the different types of patches they put out.  There are updates for the operating systems that run on affected systems (Windows, MacOS and Linux), updates for web browsers that run on those operating systems, and updates for the UEFI firmware and BIOSes of the computers with vulnerable processors.  

Both Intel and AMD worked and are working with the operating system vendors and the hardware vendors to create fixes, but many consumers and IT departments aren’t clear on exactly where the responsibility for creating the updates lies, and whether they should be installing all, some, or none of available patches. This guide can help you sort out some of the different patches that have been released.

Other ramifications

Not only has the Spectre/Meltdown fiasco created a big mess for IT professionals and home and business computer users, it has also been a PR disaster for Intel and is creating some legal issues for the big tech companies that kept the knowledge of the vulnerabilities to themselves for weeks or months.  CEOs of Intel, AMD, ARM, Apple, Microsoft, Amazon and Google – all of which had been made aware of the issue as early as June 2017 – were questioned about the embargo via a letter from members of the  U.S. House of Representatives’ Energy and Commerce Committee.

A number of security experts criticized the departure from standard disclosure processes, and smaller tech companies that weren’t in the loop weren’t happy about not being informed. This included anti-virus makers and some smaller cloud providers.

Some fell that the whole thing was botched, from the secrecy to the issuance of buggy patches and the ensuing confusion and chaos within the industry and among customers. Linus Torvalds, the “father” of the Linux OS, had some particularly harsh words for Intel’s handling of the patching issue.

The web is awash in discussion over whether vendors should have handled this security threat differently.  One thing that most people seem to agree upon is that there are important lessons to be learned from the incident, one of which is that the instruction set architecture (ISA) that serves as an interface between the hardware and software needs to be more secure.

Going forward

The good news is that, at least as of February 5 as I’m writing this, we aren’t seeing widespread large scale attacks based on Spectre and Meltdown. However, some security vendors are seeing more processor-vulnerability-related malware samples than others.

Meanwhile, your best first step toward defending against these vulnerabilities is to determine whether the patches have in fact been properly installed, since some AV programs can interfere.

Processor makers are already talking about how to prevent similar vulnerabilities from emerging in the future, which will require more collaboration between all the companies that design and manufacture the chips. Intel, AMD, and ARM engineers weighed in on the topic at DesignCon 2018 at the end of January after a rough month for the industry. There seems to be general agreement that just as software vendors got a wakeup call years ago that resulted in a focus on “security by design,” the same thing needs to take place now in the hardware arena.