Remedying Meltdown and Spectre Vulnerabilities

Sadly, the world (and we mean the whole world) is faced with two newly identified hardware vulnerabilities, this time with Meltdown and Spectre. These vulnerabilities are OS agnostic, being a vulnerability in modern CPU architecture (thanks Parallel Processing!). Both are able to access memory (information) from other applications and processes (control) other than their own. Two Factor Authentication, up-to-date Antivirus definitions, Principle of Least Privilege (PLP), and OS patches are your best bet in protecting against these vulnerabilities.

Meltdown and Spectre icons

Upon reading the abstracts on Meltdown and Spectre, I immediately thought of our brothers and sisters in infosec, and then Charles Dickens, and truly, “It was the best of times, it was the worst of times.” Personally, I’ve had the R.E.M. song, It’s the End of the World as We Know It (and I Feel Fine), playing over and over in my head. Except I don’t feel fine.

PLEASE NOTE: The information provided in this blog is the information we have as of Jan 04 2018 16:27 GMT-0700 (MST).

What exactly are Meltdown and Spectre?

Meltdown and Spectre are hardware vulnerabilities that allow a malicious agent to access memory from other applications and processes other than their own. This allows for accessing SSH keys, certificates, files, passwords, browser info (passwords), and passwords from password manager software (aka, all the passwords). Anything stored in memory is vulnerable, and impacts all modern (1995) x86 CPUs from Intel, AMD, as well as ARM chips. (Meltdown may be limited to Intel chips, but there’s insufficient information to say that AMD and ARM are not also impacted.)

Meltdown allows for accessing arbitrary system memory (places it shouldn’t) while Spectre is able to trick other applications into accessing arbitrary system memory. For more technical information, read the following abstracts: Meltdown and Spectre Attacks: Exploiting Speculative Execution.

What are we doing for you?

We are currently building and testing the Microsoft Windows update packages. Those should be released by the time you read this. The updates are part of the normal Windows updates, but are out-of-band, being released now instead of Tuesday, January 9, 2018. For a list of updates, please see our KB article Known Issues January 3, 2018 Windows Cumulative & Security Only Updates.

WARNING: Deploy these patches at your own risk. As with all patches, our packages are only as good as the files received from the software vendor. There are documented cases of the patches causing Blue Screens (BSODs), but we have not been able to confirm this issue in-house. The BSOD issues that have been reported to this point appear to be related to (big name) Antivirus vendors and appear have workarounds.

What else can I do?

Mitigation is what everyone wants. We recommend using Two Factor Authentication for everything that supports it (including your own domain -it’s easy), up-to-date Antivirus definitions, implement the Principle of Least Privilege (PLP), and OS patches. While there are no known detections of Meltdown & Spectre in any Antivirus (AV) software, their delivery mechanism may be detected.

Meltdown already has patches available from major OS vendors. For third-party software vendors, Meltdown will likely have patches released soon. Spectre, on the other hand, will likely take quite some time to patch (some say years), and the only mitigation strategy at this point is detecting and eliminating the delivery agent through AV.

You can check if your Windows desktop OS machines are vulnerable to Meltdown by using the following PowerShell provided by Microsoft.

Install-Module SpeculationControl


Below is a sample output from a vulnerable machine:

For Windows Servers, there are some additional registry modifications from Microsoft that need to take effect first before applying a patch.

After you have patched your server systems, you can run the PowerShell script on these servers.

Additional Resources

The information about these vulnerabilities is being made available at lightning speed, so here are some other valuable resources:

Company Link Link Link
Intel Security Advisory Security Research Findings
ARM Security Update
AMD Processor Security
Microsoft Security Update Guide Antivirus Software Info Azure blog
Amazon Security Disclosure
Google Project Zero Blog Cloud, G Suite, Chrome
Mozilla Security Blog
Red Hat Vulnerability Response
Debian Security Tracker
Ubuntu Knowledge Base
SUSE Vulnerability Response
CERT Vulnerability Notice VU#584653
MITRE CVE-2017-5715 CVE-2017-5753 CVE-2017-5754
VMWare Security Advisory VMSA-2018-0002
Citrix Security Bulletin

Follow @admarsenal on Twitter

12 responses

  • How about making a PDQ Inventory report which will show which machines are impacted by this? Just like PDQ did with the Intel SA-00086 vulnerability.

  • Thanks for this Brigg.

    Has anyone figured out something clever to do w/ the Get-SpeculationControlSettings output? The best I’ve come up w/ is Get-SpeculationControlSettings | Export-Csv -Path “c:\temp\$env:computername-spec.csv” ** (or more likely, to a network location). This is per machine output which would have to be aggregated – a report that brought it together would be of interest from both an operational and governance perspective.

    ** Sample CSV output from unpatched windows box :
    #TYPE System.Management.Automation.PSCustomObject

    Regards – Pete

  • As a follow-up, we’re using PS, writing the output into our own registry keys and have a registry scan profile in place. Dynamic collections separate targets into different categories of ‘requiring remediation’, ‘re-mediated’, etc.

    Regards – Pete

    • I was thinking of doing just this, then combining it with a scan to ensure that the regkey to allow Windows updates is in place.

  • Anyone who can share their scripts to get the Get-SpeculationControlSettings into the registry and generate a dynamic collection based on a custom registry scan profile ?

    • There are probably easier/quicker/more efficient methods, but this is my quick and dirty way to get the info to the registry. Now I just have to Powershell updated on my endpoints so that NuGet will work.

      set-psrepository -name "PSGallery" -InstallationPolicy Trusted
      Install-PackageProvider -Name NuGet -MinimumVersion -Force
      install-module SpeculationControl
      $results = get-speculationcontrolsettings
      $path = "HKLM:\SYSTEM\"
      remove-item -path "HKLM:\SYSTEM\SpeculationControlStatus" -force

      New-Item -path $path -Name SpeculationControlStatus
      new-itemproperty -path $path\SpeculationControlStatus -name "BTIHardwarePresent" -value $results.BTIHardwarePresent -PropertyType string
      new-itemproperty -path $path\SpeculationControlStatus -name "BTIWindowsSupportPresent" -value $results.BTIWindowsSupportPresent -PropertyType string
      new-itemproperty -path $path\SpeculationControlStatus -name "BTIWindowsSupportEnabled" -value $results.BTIWindowsSupportEnabled -PropertyType string
      new-itemproperty -path $path\SpeculationControlStatus -name "BTIDisabledBySystemPolicy" -value $results.BTIDisabledBySystemPolicy -PropertyType string
      new-itemproperty -path $path\SpeculationControlStatus -name "BTIDisabledByNoHardwareSupport" -value $results.BTIDisabledByNoHardwareSupport -PropertyType string
      new-itemproperty -path $path\SpeculationControlStatus -name "KVAShadowRequired" -value $results.KVAShadowRequired -PropertyType string
      new-itemproperty -path $path\SpeculationControlStatus -name "KVAShadowWindowsSupportPresent" -value $results.KVAShadowWindowsSupportPresent -PropertyType string
      new-itemproperty -path $path\SpeculationControlStatus -name "KVAShadowWindowsSupportEnabled" -value $results.KVAShadowWindowsSupportEnabled -PropertyType string
      new-itemproperty -path $path\SpeculationControlStatus -name "KVAShadowPcidEnabled" -value $results.KVAShadowPcidEnabled -PropertyType string

  • Folks – here’s my exported PDQ Deploy Package for enabling Get-SpeculationControlSettings on to remote workstations and writing to registry. Note that it is dependent on SpeculationControl.psd1 && .psm1 being in $(Repository)\Microsoft\PowerShell\Modules\SpeculationControl\1.0.2 for the File Copy Step. I didn’t test for existence – they are Forced everytime the script runs.

    The PDQ Inventory scan is just a registry scan profile for the written hive.

    I’ve redacted the hive name we’re writing to w/ ‘REDACTED’.






    C:\Program Files\WindowsPowerShell\Modules\SpeculationControl\1.0.2





    File Copy

    get-module SpeculationControl

    $data = Get-SpeculationControlSettings


    Set-Location HKLM:

    New-Item -Path .\Software\ -Name REDACTED -Force

    $array = “BTIHardwarePresent”, “BTIWindowsSupportPresent”, “BTIWindowsSupportEnabled”, “BTIDisabledBySystemPolicy”,”BTIDisabledByNoHardwareSupport”, “KVAShadowRequired”, “KVAShadowWindowsSupportPresent”, “KVAShadowWindowsSupportEnabled”, “KVAShadowPcidEnabled”

    foreach ($_ in $array) {New-ItemProperty -Path .\Software\REDACTED -Name $_ -Value $data.$_ -PropertyType String -Force}






    Get-Module and run Get-SpeculationControlSettings


    Speculation Control Status Scan
    Custom and Imported Packages\Packages\Meltdown/Spectre\Speculation Control Status Scan


  • Apologies – I guess posting eats the XML tags. You can see the script commencing after the file copy. If there is a way of escaping and posting the XML export – let me know and I’ll try again.

Your email address will not be published.

Your Name

This site uses Akismet to reduce spam. Learn how your comment data is processed.