Patching Windows for Spectre and Meltdown: A complete guide

On May 21, 2018, Google Project Zero (GPZ), Microsoft and Intel disclosed two new Spectre- and Meltdown-related chip vulnerabilities: Speculative Store Bypass (SSB) and Rogue System Registry Read. The customer risk from both disclosures is low. Then on June 13, 2018, Intel released a security advisory on the Lazy FP State Restore vulnerability, CVE-2018-3665, involving side channel speculative execution.

Spectre and Meltdown pointed out the need to proactively patch firmware. To recap why these vulnerabilities are dangerous, both can allow hackers to access data from a computer’s memory using side channels, circumventing protective mechanisms. Spectre and Meltdown impact AMD, ARM, Nvidia and Intel processors and prey on technologies designed to speed up computers.

Although there are no known exploits of the earlier or new Spectre and Meltdown vulnerabilities, each has the potential to expose sensitive data. Microsoft has previously released patches for Windows to mitigate the risk of earlier Spectre and Meltdown vulnerabilities, and it has recently added patches for the new vulnerabilities. Below is a summary of the Common Vulnerability and Exposures (CVEs) representing side channel vulnerabilities known as this time and advice on deploying Microsoft’s patches for them.

Spectre and Meltdown patch notes

The fixes to prevent these vulnerabilities include a software patch from Microsoft and a hardware BIOS or firmware update. If you do not have both pieces, you will not be fully protected. Also, be aware that many of these patches impact performance of the machine. That’s why many of these updates are not enabled by default for server operating systems and you need to manually enable the mitigation.

Many of the patches released in May and July are not enabled for desktop systems as well. The patching administrator needs to determine if you can accept the risk and not enable these updates.

Remember that these vulnerabilities depend on malware running locally to successfully launch an exploit. Users and administrators need to practice good security hygiene by keeping their software up-to-date and avoid suspicious links and downloads.

How to patch Microsoft Windows for Meltdown and Spectre

The only long-term fix for all Spectre and Meltdown vulnerabilities is to totally redesign chipsets, and there are no new chipsets on the immediate horizon. In the meantime, these are the best options for mitigating Spectre and Meltdown risk on Windows systems.

Bounds Check Bypass (CVE-2017-5753) and Branch Target Injection (CVE-2017-5715)

A proof of concept has been published, but as of this posting, no attacks have been seen in the wild. Microsoft includes these Spectre vulnerabilities in one advisory. They prey on systems with microprocessors that use speculative execution and branch prediction, and they might allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.

To enable this update you need to install firmware updates as well as any Microsoft software update released since March 2018. Inventory your systems to determine what hardware is installed on your machines. You can use various scripts or PowerShell to do this. Next, review the Intel Microcode update page to determine what updates you need for your hardware. If you have machines that will not receive an update, you will need to review the risk they present.

Rogue Data Cache Load (CVE-2017-5754)

This Meltdown vulnerability preys on systems with microprocessors that use speculative execution and indirect branch prediction. Patch these vulnerabilities using the same process for the two vulnerabilities described above.

Windows patches for Rogue Data Caches are enabled by default for workstations but not on servers. As noted in the Microsoft security advisory, the following are most at risk:

• Hyper-V hosts, which require protection for virtual machine (VM) to VM and VM to host attacks
• Remote Desktop Services Hosts (RDSHs), which require protection from one session to another session or from session to host attacks.
• Physical hosts or VMs that run untrusted code such as containers or untrusted extensions for database, untrusted web content, or workloads that run code provided by external sources. They require protection from untrusted process to another process or from untrusted process to kernel attacks.

To apply the mitigation on servers, enable the mitigation via the following registry key process to enable the fix:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization" /v MinVmVersionForCpuBasedMitigations /t REG_SZ /d "1.0" /f

Once you have enabled the mitigation, you might have issues performing live migrations unless all machines have been updated. Use PowerShell to determine if you are patched following these steps:

1. Select PowerShell Verification using the PowerShell Gallery (Windows Server 2016 or WMF 5.0/5.1)
2. Install the PowerShell module by launching PowerShell with administrative rights. Then type:
   Install-Module SpeculationControl
3. Run the PowerShell module to validate the protections are enabled:
   

   # Save the current execution policy so it can be reset
    $SaveExecutionPolicy = Get-ExecutionPolicy
    Set-ExecutionPolicy RemoteSigned -Scope Currentuser
    Import-Module SpeculationControl
    Get-SpeculationControlSettings
    # Reset the execution policy to the original state
    Set-ExecutionPolicy $SaveExecutionPolicy -Scope Currentuser

Alternatively, you can use PowerShell Verification using a download from Technet for earlier OS and Windows Management Framework (WMF) versions.

1. Install the PowerShell Module from Technet ScriptCenter
2. Download SpeculationControl.zip to a local folder.
3. Extract the contents to a local folder--for example, C:\ADV180002
4. Run the PowerShell module to validate the protections are enabled
5. Start PowerShell, then (using the example above), copy and run the following commands:
   

   # Save the current execution policy so it can be reset
    $SaveExecutionPolicy = Get-ExecutionPolicy
    Set-ExecutionPolicy RemoteSigned -Scope Currentuser
    CD C:\ADV180002\SpeculationControl
    Import-Module .\SpeculationControl.psd1
    Get-SpeculationControlSettings
    # Reset the execution policy to the original state
    Set-ExecutionPolicy $SaveExecutionPolicy -Scope Currentuser

The resulting output will be as follows:

Susan Bradley

The module will install.

Susan Bradley

Click Yes to install the module.

Susan Bradley

Click yes to adjust the execution policy, which resets to normal when the process is done.

Susan Bradley

The script will indicate if you are fully protected. In this sample test, the machine has operating system updates installed, but not firmware updates.

If your host has not installed firmware updates for virtualized Server 2016 servers, you can use an alternative process to protect the systems. The idea for the alternative process is to ensure that the Hyper-V clients have isolation set.

These hosts may be configured to provide isolation between the virtual processors (VPs) used for the Hyper-V host’s root partition and guest virtual machines. There are two features in Windows Server 2016 Hyper-V that allow for such a configuration:

• The minimum root, or “Minroot,” capability allows the host administrator to constrain the Hyper-V host partition to run its virtual processors on a subset of the system’s total logical processors (LPs). The remaining LPs are still available to the hypervisor to run VMs.
• The CPU Groups feature may be employed to constrain guest VM virtual processors to specific LPs.

Speculative Store Bypass (SSB) Variant 4 (CVE-2018-3639)  

Enable mitigations for Speculative Store Bypass together with mitigations for Branch Target Injection and Rogue Data Cache Load through the following registry settings (they are not enabled by default). Note that these registry changes require administrative rights and a restart:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 8 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

Microsoft has reported some performance impact when the Speculative Store Bypass patch is turned on. However, the actual performance impact depends on multiple factors, such as the specific chipset in your physical host and the workloads that are running.

Rogue System Registry Read Variant 3a (CVE-2018-3640)

This vulnerability impacts systems with microprocessors that use speculative execution and perform speculative reads of system registers may allow unauthorized disclosure of system parameters to an attacker with local user access via a side-channel analysis. An attacker who successfully exploits this vulnerability can bypass Kernel Address Space Layout Randomization (KASLR) protections. To exploit this vulnerability, an attacker would have to log onto a vulnerable system and run a specially crafted application.

The mitigation for this vulnerability is exclusively through a microcode/firmware update, and there is no additional Microsoft Windows operating system update. Microsoft Surface devices will be patched by Microsoft but are still being worked on at this time. Microsoft still sees the risk of attack as low. You can monitor the status of the updates on this Microsoft page.

Lazy FP State Restore (CVE-2018-3665)

This vulnerability impacts system software that uses the Lazy Floating Point (FP) State Restore technique on systems using Intel Core-based microprocessors. The vulnerability might allow a local process to infer data from another process through a speculative execution side channel. An attacker, via a local process, could cause information stored in FP, MMX and SSE register states to be disclosed across security boundaries on Intel Core family CPUs through speculative execution.

An attacker must be able to execute code locally on a system to exploit this vulnerability, similar to the other speculative execution vulnerabilities. The information that could be disclosed in the register state depends on the code executing on a system and whether any code stores sensitive information in FP register state.

On July 10, 2018, updates for Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and x64-based versions of Windows 8.1 and Windows 10 were released. At this time only Intel processors are protected, AMD fixes are still in the works.

Bounds Check Bypass Store (BCBS) (CVE-2018-3693)

This vulnerability was disclosed on July 10, 2018. At this time, it does not appear that Microsoft software has flaws for this vulnerability, but more investigation is underway. The Intel version of the vulnerability indicates that microcode updates are not needed.

Microsoft has indicated that the impact to Azure for the Intel mitigation will be minimal, but if you see a performance hit in Azure, you should enable Azure accelerated networking (Windows, Linux). Be aware that at this time virtual server machines in Azure are built with the May releases and thus are vulnerable to several of these vulnerabilities as patches were only released in July. Review your VMs for patching status.

Spectre and Meltdown information for databases and developers

You need to review the impact of Spectre and Meltdown on databases as well as your operating systems. Microsoft has released guidance for SQL Server as well as guidance for ensuring that developed software is designed to prevent speculative execution side channel vulnerabilities in software.

For SQL Server, you might need to review additional mitigation techniques as noted. Evaluate what SQL Server extensibility features you might be using and what additional mitigation steps you might need to take. These include:

• SQL CLR assemblies
• R and Python packages running through the external scripts mechanism or run from the standalone R/Machine Learning Studio on the same physical machine as SQL Server
• SQL Agent extensibility points running on the same physical machine as SQL Server (ActiveX scripts)
• Non-Microsoft OLE DB providers used in Linked Servers
• Non-Microsoft Extended Stored Procedures
• COM objects executed within the server (accessed via sp_OACreate)
• Programs executed via xp_cmdshell

Performance impact

These mitigations can have performance impact once the patches and microcode/firmware updates are installed. As Microsoft states, the impact for most consumer devices might not be noticeable. Again, actual performance impact depends on the hardware generation and implementation by the chip manufacturer, among other factors.

Benchmark testing has shown an impact of 5 percent to 6 percent. Microsoft indicated the following impact: