The latest computer flaws to make global headlines are ominously titled “Spectre” and “Meltdown” and they represent a unique breed of trouble, requiring unprecedented industry collaboration and manual remediation steps to fully mitigate. Unlike traditional software vulnerabilities that organizations usually encounter, these flaws occur at the chip level, and impact, to various degrees of risk, billions of computers worldwide. In fact, they could affect almost every desktop computer and server manufactured since 1995, according to one of the researchers who discovered the flaw; the key being the “out-of-order” speculation technologies that chip manufacturers raced to implement in the age of the home computer boom. As mobile phones and embedded platforms have felt the same pressures to produce ever-increasing speeds while keeping power low, they too have implemented similar technologies, which, for example, rendered every recent iPhone equally at risk of attack.
More importantly, between each processor manufacturer — and sometimes even within models produced by a single chip designer — the level of risk posed by these vulnerabilities can greatly vary. Muddying the waters even further, even though there are two media-friendly names associated with these flaws, the CVEs (common vulnerabilities and exposures) numbers and technical papers by the finders reveal that there are actually three different vulnerabilities involved, each with its own “call to action” for full remediation — which in some cases won’t ever be possible.
These design flaws were discovered by Google and other independent researchers last year and were immediately revealed to chip manufacturers, OS developers and cloud computing providers. The flaws violate central computer science isolation principles that laid the foundation for modern sandboxing that protects your applications from attack by a browser; multi-user computing that protects your documents from another user logged into the same server; and multi-tenancy that protects your entire virtual machine from another virtual machine on the same metal host. Due to this unprecedented impact and the inability for processor manufacturers to easily mitigate all the flaws in hardware, a decision was made to delay making the vulnerabilities public for six months, giving software vendors time to create patches or workarounds, while chip designers altered future tape-outs and looked for possible mitigations on current generation chips.
Just like an impressive set of computer science skills were used by Jann Horn and others to discover and prove these flaws existed (with assistance from chip makers or access to non-public information), brand new computer science had to be invented in some cases for software makers to mitigate against the flaws — a good example being Google’s “Retpoline” paper, which was shared with other vendors. Another acknowledgement should go to Amazon for their “Vixen” technique to protect Xen from Variant Three, or Citrix’ similar “PV-in-PVH” technology.
Additionally, these mitigations, sometimes costly, had to be measured and weathered against their impact on user experience and cloud computation efficiency losses, while evaluating their risk. In the end, even though the announcement had to be moved up a week due to some mistakes made in the last few days of making the Linux patches publicly visible for merging, the six-month delay was critical, and ultimately successful. Potentially catastrophic consequences were avoided, which could have resulted if adversaries had been made aware of the flaws before they could be mitigated.
The Fixes Available for the Three Design Flaws
Since the news broke on January 3, Meltdown and Spectre have been covered by a wide range of publications, with many vendors and analysts weighing in on the flaws and their potential impact. For example, Google offers detailed coverage in their security blog. The good news is that vendors have been diligently collaborating and quietly releasing patches over the last few weeks so that many of the significant risks have been patched — mitigating the risk for end users that are painstaking in maintaining the hygiene of their systems. The following is a summary of fixes available for the three flaws:
- Variant One, Bounds Check Bypass (CVE-2017-5753): Fixing this variant requires obtaining custom-compiled binaries from vendors. All major browsers have provided patches, and Linux’s kernel JIT engine requires a patch, as well. Other JIT-type applications/libraries/kernel components, which run arbitrary code, will require individual patches.This vulnerability is one which is most likely to be used by a remote attacker through an existing bug in a browser or other sandboxed parsing application, allowing the attacker to bypass existing security mitigations such as ASLR and potentially read user data it should not be able to. Customers that use older browsers or lesser-known such applications whose vendors are not up-to-date with these vulnerabilities are the most at risk, as well as such applications that are running on systems that are hard to patch, such as embedded/industrial systems.
- Variant Two, Branch Target Injection (CVE-2017-5715): Fixing this variant requires a Microcode update from Intel and AMD that is being delivered through their OEM partners (computer and motherboard manufacturers), as well as a patched OS kernel — and potentially a hypervisor, if operating in a virtual machine environment — that leverages the microcode update. Windows kernels have a patch available to leverage the new microcode, and Linux is currently merging such a fix into their mainline kernel for release to distribution. Additionally, Apple also has a patch available. Without the microcode update, Google’s software workaround (the retpoline) can be used, but it requires custom compiler support and recompiled binaries which leverage the technique. GCC as well as Clang/LLVM, the major open source compilers, now have support for generating such retpolines, while Windows and Visual Studio are not currently pursuing this approach. In addition, Linux has a patch in progress to be merged to mainline that uses retpolines, but it is not known at this time if Apple is using them.This vulnerability not only affects the same types of applications as Variant One, but is also the one most likely to be used against cloud and other shared virtualization providers in order to bypass traditional OS/VM boundaries. Additionally, it is the one that affects the largest number of processors and which requires the most complex set of fixes — including a microcode update as described earlier. To make matters worse, it has the biggest performance impact, especially on older hardware. These combinations of factors make it likely that older servers will perform poorly, while older embedded hardware is likely never to be fully protected. As an example of the sheer complexity of fixing Variant Two — in the context of a hypervisor — one can look at Citrix’s patches for mitigating against this vulnerability on the Xen hypervisor.
- Variant Three, Rogue Data Cache Load (CVE-2017-5754): Fixing this variant requires OS-level patches as well as hypervisor-level patches in a multi-tenant environment. It is one of the easiest to patch as it does not require any recompiled user-space applications or compiler changes. Another positive is that this vulnerability mainly affects only Intel processors and certain custom ARM64 processors, unlike Variant Two which has been said to even affect SPARC and RISC systems.That’s where the positives end, unfortunately, as this variant’s mitigations also come with potentially large performance costs on older generation hardware and the current “shim” mitigation done by Amazon and Citrix for their Xen hypervisors is also causing measurable loss in cloud computing efficiency. Equally important, while all major OS flavors — Windows, MacOS and Linux — have patches available, they only target 64-bit versions of their respective operating systems. While 32-bit Linux users may be able to leverage grsecurity patches, x86 Windows users are currently left out in the cold since mitigating this issue on 32-bit systems is even more complex and costly, potentially eliminating the risk/benefit ratio.
The information above contains thorough technical details, so here are the key caveats to consider:
- Patching Variant Three is easier because it is a single OS patch (the hypervisor should be patched by your provider), while Variant One requires multiple binaries to be recompiled by the vendors and updated by your IT department. Variant Two requires an OS patch — again, a hypervisor patch — plus individual binaries must be updated, such as browsers. In addition, a microcode update must be applied in order for the mitigation to be most effective and perform optimally, especially when Retpoline is not in use.
- Patches for Variant Two and Variant Three at the Windows OS level are currently only being distributed if your 3rd party antivirus has set a special registry key, or if your IT department manually sets the key and/or pushes the installation files manually. If CrowdStrike Falcon® server is your Windows Security-Center-registered-Antivirus, and you are running 3.9.6008 or later, CrowdStrike® will set this key for you, as Falcon is fully compatible with the patches. Additionally, on server systems, registry keys must manually be set for Variant Two and Variant Three patches to be ‘activated’ by the kernel — regardless of hardware/microcode support. Finally, no patches are currently available for x86 Windows.
CrowdStrike Recommendations and Tools to Track Mitigation Status
In the face of these three vulnerabilities, it is essential that organizations patch their systems and maintain a vigilant security posture. However, there are potentially significant performance impacts that patching certain systems — older hardware and critical I/O-bound servers — can cause, and in some situations, risks may not warrant aggressive patching without further performance and compatibility concerns. In some cases, patching an old AMD systems has even caused OS-level crashes — the “blue screen of death” — causing Microsoft to pull the patch. On Tuesday, Microsoft published the preliminary results of these patches on Windows systems on their blog.
CrowdStrike Falcon customers currently benefit from the built-in exploit and behavioral blocking features of Falcon, and are able to patch their systems with no effect on their protection. Although there is currently no evidence of any exploits leveraging the Meltdown/Spectre vulnerabilities, attackers seeking to exploit them would be detected by Falcon’s behavioral indicators of attack (IOAs). Currently, all released versions of Falcon are fully compatible with the Windows, Mac, and Linux patch updates provided by the respective operating system vendor. Windows users should note that Falcon must be registered as your current antivirus to safely apply Windows patches with the Windows-provided registry keys.
CrowdStrike has released a new Windows sensor that will automatically set the registry keys to enable customer to download the Windows patch updates. Additionally, the sensor will include visual dashboards in the Falcon management console showing all patched and unpatched systems — providing immediate visibility across your endpoints to ensure all are patched and your organization protected. Until the dashboards become fully available to all customers, or if you have not yet been able to update, we recommend using Microsoft’s PowerShell scriptlet available here.
Finally, users are strongly advised to install firmware updates to receive the appropriate microcode changes to Windows patches. Before deploying a patch, CrowdStrike recommends that it be verified and validated. Finally, please see Microsoft’s Client and Server Guidance if you have additional questions about Azure interoperability, Windows Update deployment and general compatibility.
To learn more about the CrowdStrike Falcon platform, Contact CrowdStrike or call: 1.888.512.8906