One Year Later: Ensuring Windows Is Protected From Meltdown+Spectre

The year of speculative execution bugs

A year ago, in January 2018, three hardware vulnerabilities known as Meltdown, Spectre Variant 1, and Spectre Variant 2 were disclosed to the public.

Although disclosure was supposed to occur on January 9, news outlets found updates in the Linux Kernel and broke word early on January 3, kicking off the year with a pretty big headache for IT and security teams across the globe.

These vulnerabilities were described in detail in different papers and articles quite rapidly following the disclosure. A summarized way to describe the vulnerabilities would be that speculative execution, a feature used by CPUs to predict what to do next and improve performance, could be exploited to get programs to reveal information they should not have access to. The full papers are a great read.

During the first weeks, information on what patches to deploy, features to enable, and what vulnerability they actually fixed were updated daily, causing a great deal of confusion.

For example:

• Windows Server updates did not mitigate the issue unless a new setting was enabled, due not only to potential performance issues as well as incompatibilities with AV.
• Hypervisors, hardware and operating systems all required different software and firmware updates, making it quite hard to understand what systems were vulnerable or not.
• The attack requires some amount of code execution, as such, web browsers were a prime target, and the first mitigations for Chrome were not enabled by default.
• It was known hardware would need to be updated for a “real” fix, but the level of success of the patches was not well understood.
• Updates were pulled by hardware manufacturers, hypervisor vendors and operating system vendors, then re-issued.
• Performance impacts were feared, as they varied wildly based on workloads.

Through the year, similar vulnerabilities were discovered, which thankfully could also be mitigated by the existing patches.

The good news? No obvious, large-scale attacks using Meltdown or Spectre have been reported. As vulnerabilities that are still present in many systems, and will remain present forever on some, the odds that they will be leveraged at some point are not eliminated. That is why it is good practice, on the one year anniversary, to do a check of your Windows systems.

Using Osquery to Check Our Windows Systems

Given the problems with AV after the early patches, and the fact that updates are not enabled by default on servers, the confidence level that mitigation was applied properly on Windows systems is often low.

Microsoft has created a PowerShell module that checks multiple patch levels and configurations, to tell us if a system is protected.

You can run it the following way:

Install-Module SpeculationControl

Import-Module SpeculationControl

Get-SpeculationControlSettings

This is great for an ad-hoc check of an individual system. At scale, using osquery with the kva_speculative_info table allows us to keep track of these values on all of our Windows workstations and servers. This table was added to osquery in January 2018 making users with a well managed, centralized and updated osquery deployment already enabled to easily track their exposure to Meltdown and Spectre.

Why is this still relevant, then? Quite simply, because mistakes happen, new systems might be missing CPU or hypervisor updates, and an operating system could be configured badly.

On the same system, running select * from kva_speculative_info; generates the following:

Depending on your CPU architecture, and if the system is a workstation or server, you may be looking at different results when running this query. Either way, there are a few results you should expect and track:

• bp_mitigations should always return 1, as it indicates Branch Prediction mitigations are enabled.
• bp_system_pol_disabled should always be set to 0, as 1 would mean the mitigations are either disabled by Group Policy (pol).
• bp_microcode_disabled should always be set to 0, as 1 would mean the mitigations are disabled due to lacking support at the CPU microcode level.

The detailed output of the PowerShell module and the Osquery schema description of the table have great information about the other fields.

Once you have started tracking these values on your Windows systems, you can remediate forgotten systems, provide solid proof to auditors for compliance purposes, and most of all, be ready if more attacks start to materialize.

Fun fact: The Spectre paper contains the word “Gadget”, which is used 54 times.