This article summarizes my journey with Azure VM servers patching after the announcement of the 3 critical vulnerabilities that were discovered last week.
These vulnerabilities are named Meltdown (CVE-2017-5754) and Spectre (CVE-2017-5753 & CVE-2017-5715).
My starting point was the following article Guidance to mitigate speculative execution side-channel vulnerabilities that helped me to identify the following 4 principal steps:
- OS patching
- Firmware patching
- Registry key changes
- Verifications
OS patching
The list with all the patches is presented in the following article Guidance to mitigate speculative execution side-channel vulnerabilities.
Before deploying the patch on the PC or Server is mandatory to have the following registry key otherwise the patching deployment is not working:
Key=”HKEY_LOCAL_MACHINE”
Subkey=”SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat”
Value Name=”cadca5fe-87d3-4b96-b7fb-a231484277cc”
Type=”REG_DWORD”
Data=”0x00000000”
The registry key was already deployed for all Azure VM by Microsoft before applying the OS patching. For your Onpremise environment check the recommendations from the following article KB4056890.
Firmware patching
In Azure Microsoft is taking care of the patching, see the info in the following article Securing Azure customers from CPU vulnerability.
For onpremise check with you vendor to update the processor microcode.
Registry key changes
Create the following registry keys to enable the mitigations on the server. I have deployed all the registry keys via GPO:
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
This key is applicable only for the host and not for the guest
reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization” /v MinVmVersionForCpuBasedMitigations /t REG_SZ /d “1.0” /f
Additional information Protecting guest virtual machines from CVE-2017-5715 (branch target injection).
If this is a Hyper-V host: fully shutdown all Virtual Machines
Restart the server for changes to take effect.
The complete procedure can be found in the following article Windows Server guidance to protect against speculative execution side-channel vulnerabilities. The steps are continuously updated by Microsoft and there are major differences between the article versions.
Verification
The following commands can be executed to verify if the protection has been enabled:
Install the PowerShell Module
PS> Install-Module SpeculationControl
Run the PowerShell module to validate the protections are enabled
PS> # Save the current execution policy so it can be reset
PS> $SaveExecutionPolicy = Get-ExecutionPolicy
PS> Set-ExecutionPolicy RemoteSigned -Scope Currentuser
PS> Import-Module SpeculationControl
PS> Get-SpeculationControlSettings
PS> # Reset the execution policy to the original state
PS> Set-ExecutionPolicy $SaveExecutionPolicy -Scope Currentuser
My actual output is the following
The results should be the following ones:
PS C:\> Get-SpeculationControlSettings
Speculation control settings for CVE-2017-5715 [branch target injection]
Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: True
Speculation control settings for CVE-2017-5754 [rogue data cache load]
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID optimization is enabled: True
Updates
- 17.01.2018
There are multiple clients that are complaining about the Speculation Control script from here: Speculation Control Validation PowerShell Script.
I have opened a ticket to Microsoft and they have confirmed that Host Level patches (the OS – VM patches are client responsibility) are already applied in Azure.
Microsoft cannot assume responsibility for a script (or the script results) that wasn’t tested on Azure Environment.
Please see also the Disclaimer of the script:
Disclaimer —
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
Conclusions
Microsoft is still working on the Firmware patching and on different workarounds for identified issues.
Performance impact
I saw a lot of complaints from customers that after installing the firmware update their CPU increased from 5% to 30%. If 5% can be tolerated 30% is not acceptable.
I have tested the performance on Azure VM before and after the update – no impact
Processor: % Privileged Time
Memory\Available Bytes
Other recommendations
Enable site isolation in Chrome:
Google’s site isolation feature improves security for Chrome browser users. When you enable site isolation, content for each open website in the Chrome browser is always rendered in a dedicated process, isolated from other sites. This creates an additional security boundary between websites.
Additional information:
Actions required to mitigate Speculative Side-Channel Attack techniques
I have enabled the site isolation via GPO (you need Google Chrome ADMX templates in AD)
- Enabled site isolation via GPO but the change is not reflected in the user interface – the status is enable and not enabled
- If we check the registry key it is successful deployed on the PC
- If we manually enable site isolation – no changes at the registry key
If the registry key is there my assumption is that the setting is active.
Check the know issues presented in the following article before going in PROD: Site Isolation.
END
I am ending with some updates from the media regarding this topic:
After receiving reports of unbootable PCs, Microsoft decides to pause its distribution of Meltdown and Spectre security updates for AMD machines. It seems customers reported devices going in an unbootable state once the new updates were installed.
According to Microsoft, the unexpected behavior is due to the AMD chipsets which “do not conform to the documentation previously provided to Microsoft to develop the Windows operating system mitigations to protect against the chipset vulnerabilities known as Spectre and Meltdown”.
Microsoft and AMD are working to solve the problem and affected owners need to visit the Microsoft support site.
The Intel CEO Brian Krzanich talked about the security and speed issue surrounding Meltdown and Specter at Intel’s CES keynote. He assured that for the “processors and products introduced in the past five years, Intel expects to issue updates for more than 90 percent within a week, and the remaining by the end of January”, at the same time, pointing out the importance of an industry-wide collaboration.
So far none of these vulnerabilities have been exploited and no customer data loss have been recorded.