Windows 10: Q3 2018 Intel Speculative Execution Side Channel Update

Brink · Aug 14, 2018

Intel ID: INTEL-SA-00161 Product family: Multiple Impact of vulnerability: Information Disclosure Severity rating: See Security Advisory text Original release: 08/14/2018 Last revised: 08/14/2018
Summary:

Security researchers have identified a speculative execution side-channel method called L1 Terminal Fault (L1TF). This method impacts select microprocessor products supporting Intel® Software Guard Extensions (Intel® SGX). Further investigation by Intel has identified two related applications of L1TF with the potential to impact additional microprocessors, operating systems, system management mode, and virtualization software. If used for malicious purposes, this class of vulnerability has the potential to improperly infer data values from multiple types of computing devices.

Intel is committed to product and customer security and to coordinated disclosure. We worked closely with other technology companies, operating system, and hypervisor software vendors, developing an industry-wide approach to mitigate these issues promptly and constructively.

For facts about these new exploits, technical resources, and steps you can take to help protect systems and information please visit: Side Channel Methods – Analysis, News and Updates.

Description:

CVE-2018-3615 - L1 Terminal Fault: SGX

Systems with microprocessors utilizing speculative execution and Intel® software guard extensions (Intel® SGX) may allow unauthorized disclosure of information residing in the L1 data cache from an enclave to an attacker with local user access via a side-channel analysis.

7.9 High CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N

CVE-2018-3620 - L1 Terminal Fault: OS/SMM

Systems with microprocessors utilizing speculative execution and address translations may allow unauthorized disclosure of information residing in the L1 data cache to an attacker with local user access via a terminal page fault and a side-channel analysis.

7.1 High CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

CVE-2018-3646 - L1 Terminal Fault: VMM

Systems with microprocessors utilizing speculative execution and address translations may allow unauthorized disclosure of information residing in the L1 data cache to an attacker with local user access with guest OS privilege via a terminal page fault and a side-channel analysis.

7.1 High CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Affected products:

The following Intel-based platforms are potentially impacted by these issues. Intel may modify this list at a later time.
Intel® Core™ i3 processor (45nm and 32nm)
Intel® Core™ i5 processor (45nm and 32nm)
Intel® Core™ i7 processor (45nm and 32nm)
Intel® Core™ M processor family (45nm and 32nm)
2nd generation Intel® Core™ processors
3rd generation Intel® Core™ processors
4th generation Intel® Core™ processors
5th generation Intel® Core™ processors
6th generation Intel® Core™ processors **
7th generation Intel® Core™ processors **
8th generation Intel® Core™ processors **
Intel® Core™ X-series Processor Family for Intel® X99 platforms
Intel® Core™ X-series Processor Family for Intel® X299 platforms
Intel® Xeon® processor 3400 series
Intel® Xeon® processor 3600 series
Intel® Xeon® processor 5500 series
Intel® Xeon® processor 5600 series
Intel® Xeon® processor 6500 series
Intel® Xeon® processor 7500 series
Intel® Xeon® Processor E3 Family
Intel® Xeon® Processor E3 v2 Family
Intel® Xeon® Processor E3 v3 Family
Intel® Xeon® Processor E3 v4 Family
Intel® Xeon® Processor E3 v5 Family **
Intel® Xeon® Processor E3 v6 Family **
Intel® Xeon® Processor E5 Family
Intel® Xeon® Processor E5 v2 Family
Intel® Xeon® Processor E5 v3 Family
Intel® Xeon® Processor E5 v4 Family
Intel® Xeon® Processor E7 Family
Intel® Xeon® Processor E7 v2 Family
Intel® Xeon® Processor E7 v3 Family
Intel® Xeon® Processor E7 v4 Family
Intel® Xeon® Processor Scalable Family
Intel® Xeon® Processor D (1500, 2100)** indicates Intel microprocessors affected by CVE-2018-3615 - L1 Terminal Fault: SGX

Please check with your system manufacturer for more information regarding updates for your system.

Recommendations:

Intel has worked with operating system vendors, equipment manufacturers, and other ecosystem partners to develop platform firmware and software updates that can help protect systems from these methods.

This includes the release of updated Intel microprocessor microcode to our customers and partners. This microcode was previously released as part of INTEL-SA-00115.

Status of available microcode can be found here.

End users and systems administrators should check with their system manufacturers and system software vendors and apply any available updates as soon as practical.

Acknowledgements:

Intel would like to thank Raoul Strackx1,Jo Van Bulck1, Marina Minkin2, Ofir Weisse3, Daniel Genkin3, Baris Kasikci3, Frank Piessens1, Mark Silberstein2, Thomas F. Wenisch3, and Yuval Yarom4 for reporting this issue and working with us on coordinated disclosure of CVE-2018-3615 (www.foreshadowattack.com)

1 imec-DistriNet, KU Leuven, 2Technion, 3University of Michigan, 4University of Adelaide and Data61

Revision History

Revision Date Description 1.0 08/14/2018 Initial Release
CVE Name: CVE-2018-3615, CVE-2018-3620, CVE-2018-3646
Click to expand...

Source: INTEL-SA-00161

See also: Intel Side Channel Vulnerability L1TF

:)

Brink · Aug 14, 2018

Surface Guidance for speculative execution side-channel vulnerability

Surface Guidance to protect against speculative execution side-channel vulnerabilities

Applies to: Surface Pro 4, Surface Book, Surface Studio, Surface Pro (latest), Surface Laptop, Surface Pro with LTE Advanced, Surface Book 2 - 13 inch, Surface Book 2 - 15 inch

Introduction

Since January 2018, the Surface team has been publishing firmware updates for a new class of hardware vulnerabilities that involve speculative execution side channels. The Surface team has not received any information to indicate that these vulnerabilities have been used to attack customers currently, and the team continues to work closely with the Windows team and industry partners to protect customers. To get all available protection, both firmware and Windows system updates are required.

Summary

Vulnerabilities Announced in May 2018
The Surface team has become aware of new speculative execution side-channel attack variants that also affect Surface products. Mitigation of those vulnerabilities requires UEFI updates that use new microcode. For more information about the vulnerabilities and mitigations, see the following security advisories:

Microsoft Security Advisory ADV180012

Microsoft Security Advisory ADV180013

We are working with our partners to provide updates to the following Surface products as soon as we can make sure that the updates meet our quality requirements:

Surface Book 2

Surface Book

Surface Laptop

Surface Studio

Surface Pro 4

Surface Pro 3

Surface Pro Model 1796 and Surface Pro with Advanced LTE Model 1807

References

CVE-2018-3640

CVE-2018-3639

Vulnerabilities Announced in January 2018
The Surface team is aware of the publicly disclosed class of vulnerabilities that involve speculative execution side channels (known as Spectre and Meltdown) that affect many modern processors and operating systems, including Intel, AMD, and ARM. For more information about the vulnerabilities and mitigations, see the following security advisory:

Microsoft Security Advisory ADV180002

For more information about Windows software updates, see the following Knowledge Base articles:

4073757 Protect your Windows devices against Spectre and Meltdown vulnerabilities

4073119 Windows Client Guidance for IT Pros to protect against speculative execution side-channel vulnerabilities

In addition to installing the January 3 Windows Operating System Security Updates, Surface has released UEFI updates through Windows Update and the Download Center for the following devices:

Surface Book 2 - (Update history)

Surface Book - (Update history)

Surface Laptop - (Update history)

Surface Studio - (Update history)

Surface Pro 4 - (Update history)

Surface Pro 3 - (Update History)

Surface Pro Model 1796 and Surface Pro with Advanced LTE Model 1807- (Update History)

These updates are available for devices that are running Windows 10 Creators Update (build 15063) and later versions.

References

CVE-2017-5753

CVE-2017-5715

CVE-2017-5754

More Information

Note Surface hub has implemented defense-in-depth strategies. For more information, go to the following topic on the Microsoft website:

Differences between Surface Hub and Windows 10 Enterprise

Because of this, we believe that exploits that use these vulnerabilities are significantly reduced on Surface Hub.

The Surface team is focused on making sure that our users have a secure and reliable experience. We will continue to monitor and update devices as required to address these vulnerabilities and keep the device reliable and secure.
Click to expand...

Source: https://support.microsoft.com/en-us/...n-side-channel

See also: Surface devices and the new speculative execution side-channel vulnerabilities (May 2018) Surface

Brink · Aug 14, 2018

Mitigating speculative execution side channel hardware vulnerabilities

On January 3rd, 2018, Microsoft released an advisory and security updates related to a newly discovered class of hardware vulnerabilities involving speculative execution side channels (known as Spectre and Meltdown) that affect AMD, ARM, and Intel CPUs to varying degrees. If you haven’t had a chance to learn about these issues, we recommend watching by the team at TU Graz from BlueHat Israel, reading the blog post by Jann Horn (@tehjh) of Google Project Zero, or reading the FOSDEM 2018 presentation by Jon Masters of Red Hat.

This new hardware vulnerability class represents a major advancement in CPU side channel attacks and we’re sincerely grateful to the researchers who discovered these issues, our industry partners, and the many individuals across Microsoft who have worked on these vulnerabilities. Mitigating hardware vulnerabilities through changes in firmware and software is a significant industry challenge, and there has been some confusion over the past two months for users as the industry has collectively continued to work on this.

In this post, we’ll provide insight into how Microsoft has approached mitigating speculative execution side channel hardware vulnerabilities to date. We’ll do this by briefly describing how we investigated this new vulnerability class, the taxonomy we established for reasoning about it, and the mitigations we have implemented as a result. This post is primarily geared toward security researchers and engineers who are interested in deeper technical details related to speculative execution side channel vulnerabilities and their respective mitigations. If you are interested in more general guidance, please refer to our knowledge base articles for Windows Server, Windows Client, and Microsoft cloud services.

Please note that the information in this post is current as of the date of this post.

Approaching the challenge

We first learned about speculative execution side channel vulnerabilities through the discoveries made by Jann Horn of Google Project Zero. Given the potential severity and the scope of these attacks, we kicked off our incident response process to drive coordination and remediation across Microsoft and with industry partners. This ultimately led to the mobilization of hundreds of individuals across the company, but before we could get there, we needed to assess the severity, impact, and root cause of the issue.

Conventional software vulnerabilities are well-understood and are relatively easy to perform root cause analysis on (we even have automation for many cases, see VulnScan). Speculative execution side channels, on the other hand, represented a fundamentally new hardware vulnerability class with no established process for determining their severity and their impact on existing software security models. To create this process, we and others in the industry needed to thoroughly research speculative execution side channels and establish a taxonomy and framework for reasoning about their effects and possible mitigations. The Microsoft Security Response Center (MSRC) brought in experts from across Microsoft (e.g. Microsoft Research Cambridge and the Windows Offensive Security Research team), and we hired Anders Fogh (@anders_fogh), of GDATA Advanced Analytics, as a consultant whose deep expertise on CPU side channel attacks greatly contributed to our understanding of these issues. This research gave us a foundation on which we and others were able to build.

A framework for speculative execution side channel vulnerabilities

Side channel attacks consist of three phases: the priming phase which is used to place a system into a desired initial state (e.g. flushing cache lines), the triggering phase which is used to perform the action that conveys information through the side channel, and the observing phase which is used to detect the presence of the information conveyed through the side channel. These phases can occur architecturally (by actually executing instructions), or speculatively (through speculative execution).

Side channel attacks involving speculative execution have four components: a speculation primitive, which provides the means for entering speculative execution down a non-architectural path; a windowing gadget, which provides a sufficient amount of time for speculative execution to convey information through a side channel; a disclosure gadget, which provides the means for communicating information through a side channel during speculative execution; and a disclosure primitive, which provides the means for reading the information that was communicated by the disclosure gadget. These four components can be combined in different ways to create a speculation technique.

Speculation primitives

Spectre and Meltdown make use of three different speculation primitives. The first is conditional branch misprediction (e.g. CVE-2017-5753, aka Variant 1), where speculation may occur when predicting whether a conditional branch is taken or not taken. The second is indirect branch misprediction (e.g. CVE-2017-5715, aka Variant 2), where speculation may occur when predicting the target of an indirect branch (including call, jump, and return). The third deals with exception delivery or deferral (e.g. CVE-2017-5754, aka Variant 3), where speculative execution may continue past the point at which a fault will be raised. Each of these primitives can be used to enter speculative execution along a non-architectural path and attackers can attempt to trigger speculation in different ways (e.g. through training or colliding of predictors).

Windowing gadgets

Speculative execution is effectively a race condition between the retirement of the µop (micro-operation) that led to speculation and the µop being executed speculatively. Attackers must win this race condition for a disclosure gadget to execute speculatively. We have defined three categories of windowing gadgets. The first deals with non-cached loads that trigger a load from main memory which typically takes hundreds of cycles on most CPUs. The second involves a dependency chain of loads of which may or may not be non-cached. The third involves a dependency chain of integer ALU operations which have fixed-latency operations. These windowing gadgets can occur naturally in code, or they can be manufactured by attackers in certain cases.

Disclosure gadgets

The primary purpose of speculative execution in the context of a side channel attack is to trigger the execution of a disclosure gadget. This is because the disclosure gadget is responsible for accessing information that is stored in a security domain which is not architecturally visible to the attacker and conveying that information through a side channel. This could include memory content, register state, and so on. As with gadgets used in Return Oriented Programming (ROP), there are many possible examples of disclosure gadgets and their form and function will vary.

Disclosure primitives

After speculative execution of a disclosure gadget has conveyed information via a side channel, the final step is to detect the presence of that information using a disclosure primitive. Each disclosure primitive is intrinsically linked to the communication channel through which information is conveyed (e.g., CPU data cache, etc.), and the manner through which a disclosure gadget conveyed the information. There has been a significant amount of prior research into disclosure primitives for other side channels, such as FLUSH+RELOAD and PRIME+PROBE. These primitives are generally applicable to speculative execution side channels as well.

Relevance to software security models

Modern operating systems and applications depend on software security models that isolate native code on a device. These security models include concepts like virtualization-based isolation, kernel/user separation, process-based isolation, and language-based isolation (e.g. JavaScript runtime sandbox). The designs for these security models take a strong dependency on the underlying hardware guarantees that memory allocated to one security domain cannot be read from or written to by another security domain unless permitted by a privileged arbiter (such as a hypervisor, the kernel, or a managed runtime). This is enforced by the hardware and operating system through concepts like privilege modes (hypervisor, kernel, user), paging, and so on. Unfortunately, speculative execution side channel vulnerabilities can make it possible to read memory across security domains, thus violating existing software security models.

To illustrate this, the following table summarizes the relevance of speculation primitives to the attack scenarios that represent software security models of concern. Each attack scenario is described in terms of the direction that information flows when performing a speculative execution side channel attack. Orange cells indicate that the speculation primitive is applicable to the corresponding attack scenario whereas grey cells are not applicable.

Applicable Not applicable
Attack Category Attack Scenario Conditional branch misprediction Indirect branch misprediction Exception delivery or deferral Inter-VM Hypervisor-to-guest Host-to-guest Guest-to-guest Intra-OS Kernel-to-user Process-to-process Intra-process Enclave Enclave-to-any
Inter-VM

This category deals with attacks on virtualization-based isolation which relies on hardware support for virtualization extensions for security. Hypervisor-to-guest attacks involve a malicious guest attempting to read hypervisor memory. Host-to-guest attacks involve a malicious guest reading the memory of the privileged guest that provides virtualization assists (e.g. the root partition in Hyper-V or dom0 in Xen). Guest-to-guest attacks involve a malicious guest reading the memory of another guest.

Intra-OS

This category deals with attacks within a traditional instance of an operating system (e.g. the OS in a VM or on a physical device). Kernel-to-user attacks involve a malicious user mode process reading kernel memory. Process-to-process attacks involve a malicious user mode process reading the memory of another process that should not be readable. Intra-process attacks involve a process being coerced into reading its own memory such as the case of a web site providing JavaScript to a web browser which then creates the conditions for a speculative execution side channel vulnerability.

Enclave

The enclave category deals with enclave-to-any attacks where code executing outside of an enclave (e.g. an Intel SGX enclave) is able to read memory within the enclave.

Mitigations for speculative execution side channel vulnerabilities

The taxonomy and framework described above provide the basis for defining a strategy and a set of tactics for mitigating speculative execution side channel vulnerabilities. Through this process we identified three general tactics that can be employed by software (and hardware) to mitigate this issue with varying levels of completeness. These tactics are summarized in the following table:

Prevent speculation techniques Remove sensitive content from memory Remove observation channels SSpeculative execution attacks inherently rely on using a speculation primitive to execute a desired disclosure gadget. These attacks can be mitigated by preventing the use of a speculation primitive or specific instance of a speculation technique. This tactic is desirable because it mitigates the issue at or near the root cause. Speculative execution attacks rely on sensitive information being accessible in the victim’s address space. These attacks can be mitigated by removing sensitive information from memory such that it is not readable during speculative execution. This approach cannot protect against reading of register state or “non-sensitive” memory content (such as address space information). Speculative execution attacks inherently rely on the ability to communicate information through a side channel (such as CPU data caches). These attacks can be mitigated by removing channels for communication which thereby prevents the use of certain disclosure primitives. This can provide a broad mitigation that is independent of any single speculation primitive.
In the sections that follow, we will describe the mitigations we have implemented and what impact they have to the speculation techniques that have been described thus far.

Preventing speculation techniques

One of the best ways to mitigate vulnerabilities is by eliminating a class of issues at the root cause. For speculative execution attacks, this can be accomplished by preventing speculation primitives from being used to execute a desired disclosure gadget.

Speculation barrier via execution serializing instruction

This mitigation involves inserting instructions that act as a speculation barrier by serializing execution. On AMD and Intel CPUs this involves the use of an LFENCE instruction whereas ARM recommends the use of conditional select/move (CSEL/MOVS) instructions along with a new explicit barrier instruction (CSDB). Microsoft has added support for the /Qspectre flag to Visual C++ which currently enables some narrow compile-time static analysis to identify at-risk code sequences related to CVE-2017-5753 and insert speculation barrier instructions. This flag has been used to rebuild at-risk code in Windows and was released with our January 2018 security updates. It is important to note, however, that the Visual C++ compiler cannot guarantee complete coverage for CVE-2017-5753 which means instances of this vulnerability may still exist. We recommend that software developers treat CVE-2017-5753 as a new hardware vulnerability class that can be mitigated in software by adding an explicit speculation barrier. While we are continuing to look for opportunities to improve Visual C++ support for /Qspectre, Microsoft has also announced a Speculative Execution Side Channel bounty program to encourage researchers to find and report any instances of CVE-2017-5753 that may remain.

In a similar vein, the JavaScript Just-in-Time (JIT) compiler in Microsoft Edge and Internet Explorer includes code generation mitigations for CVE-2017-5753. These mitigations constrain the permissible behavior of speculative execution related to CVE-2017-5753 for dynamically generated native code that is produced by the JIT.

Security domain CPU core isolation

Modern CPUs typically store prediction state in per-core or per-SMT caches. This means that isolating workloads to distinct cores can be used to robustly mitigate speculation techniques that rely on colliding prediction state. To that end, Microsoft has published documentation describing how minimum root (“minroot”) can be used to dedicate core(s) to the Hyper-V root partition and how CPU groups can be used to dedicate core(s) to guests.

Indirect branch speculation barrier on demand and mode change

Speculation techniques that rely on one security domain (user, kernel, hypervisor) being able to influence indirect branch predictions (e.g. CVE-2017-5715) in another security domain can be mitigated through the use of additional hardware interfaces provided by Intel, AMD, and ARM. In the case of Intel and AMD, these hardware interfaces require microcode updates to expose the features of which operating systems can take advantage. These features provide software with the ability to flush indirect branch prediction state, inhibit the use of branch predictions from less-privileged security domains, and protect against sibling hardware thread prediction interference. The microcode updates from Intel and AMD are currently at varying levels of readiness and availability, but they are generally expected to enable strong mitigations for speculation techniques that use indirect branch mispredictions across security domains. On March 1st, 2018, Microsoft announced the availability Intel microcode updates through the Microsoft Update Catalog (KB4090007).

Non-speculated or safely-speculated indirect branches

Some types of indirect branches on existing Intel and AMD hardware are either not predicted at all or have generally safe prediction behavior and can therefore be used to mitigate CVE-2017-5715. For example, far JMP on existing Intel hardware is not predicted and can therefore be used as an alternative to near indirect CALL and JMP. This mitigation takes advantage of the far JMP behavior by transforming all at-risk indirect CALL and JMP instructions into far JMP for the Hyper-V hypervisor when running on Intel hardware. For the Hyper-V hypervisor running on AMD hardware, at-risk near indirect CALL and JMP are preceded by an execution serializing RDTSCP instruction as per AMD’s recommended guidance.

In a similar vein, Google has also proposed a software solution known as retpoline which transforms near indirect calls and jumps into “retpolines” that rely on safe and deterministic near return mispredictions when transferring control. This solution provides a strong mitigation for speculation techniques that use indirect branch misprediction on many existing CPUs. We believe retpoline can be a suitable mitigation for environments where it is practical to rebuild all at-risk code and we have pursued a similar path through the changes we have made to Hyper-V. We are also evaluating performance optimizations involving a hybrid mitigation for the Windows kernel and device drivers that would involve retpoline and hardware support for indirect branch speculation barriers.

There are some additional points that are important to consider regarding the use of retpoline. Some modern CPUs, as noted by Intel, do not satisfy the security properties that retpoline relies upon for near-return prediction without requiring software to prevent RSB (Return Stack Buffer) underflows. These CPUs require software to perform RSB stuffing to prevent underflow which we believe to be nontrivial for software to perform in the general case. In addition, scenarios that would require all at-risk software to be rebuilt face significant challenges in the context of expansive, multi-vendor, binary ecosystems such as multi-tenant cloud environments or traditional desktops and servers that make use of applications and other software produced by multiple vendors. For these environments, we believe it is unreasonable to expect that all at-risk software will be rebuilt. As we look toward the future, hardware security improvements such as Intel’s Control-flow Enforcement Technology (CET) will encounter compatibility issues with the use of retpoline which software developers need to consider.

Removing sensitive content from memory

All attacks involving speculative execution side channels attempt to gain access to information across security domains. This means that attackers will attempt to disclose data from a victim security domain that they should not have access to. As such, removing sensitive information from the victim security domain can be an effective method of preventing information disclosure using speculation techniques.

Hypervisor address space segregation

The Microsoft Hyper-V hypervisor has historically maintained an identity map of all physical memory to accelerate memory accesses while executing in the hypervisor (known as the “physical map”). To minimize exposure to speculation techniques, we have removed the physical map entirely and no longer map all physical memory into the address space of the hypervisor, thus helping to mitigate the risk of cross-VM information disclosure through speculative execution.

Split user and kernel page tables

This mitigation is known as Kernel Virtual Address (KVA) Shadow on Windows and it mitigates the speculation technique known as Meltdown (CVE-2017-5754) by creating two page directory bases per process. The first maps the “user” page tables which only contains user mode mappings and a small number of kernel transition pages. The second maps the “kernel” page tables which contains both user and kernel mappings for the process. The user page tables are active while executing code in user mode while the kernel pages are switched to when trapping and executing code in kernel mode on behalf of a process. This has the effect of removing sensitive kernel memory content from the virtual address space for a process which thereby provides a robust mitigation for CVE-2017-5754. This mitigation draws inspiration from prior research known as KAISER, although KVA Shadow is not intended to enable robust local Kernel ASLR (KASLR). KVA Shadow is also similar to mitigations available for the Linux kernel (Kernel Page Table Isolation, KPTI), Apple MacOS and iOS, and Google Chromebook.

Removing observation channels

All speculation techniques implicitly rely on communicating information through a side channel in a manner that can be detected by a disclosure primitive. This means speculation techniques can be broadly mitigated by removing channels for communicating and observing information.

Map guest memory as noncacheable in the root extended page tables

Virtualization software often maps guest memory into the address space of a privileged guest (the “root” for Hyper-V, or dom0 for Xen) to enable fast communication through shared memory. In the context of speculation techniques, these shared memory regions can be used to communicate information through the loading of a shared cache line (e.g. FLUSH+RELOAD). One way to mitigate this is by mapping guest memory regions as noncacheable (UC) in the extended page tables for the root. On all CPUs, noncacheable memory cannot be loaded during speculative execution and therefore prevents loading of a shared cache line.

Do not share physical pages across guests

In some cases, virtualization software may share physical pages between guests. These shared memory regions can be used to communicate information through the loading of a shared cache line (similar to mapping guest memory as noncacheable). In this case, these shared regions can facilitate guest-to-guest attacks involving speculative execution. This mitigation implements the straightforward solution which is to stop sharing physical pages between guests that are not part of the same security domain.

Decrease browser timer precision

The intra-process attack scenario is relevant to web browsing scenarios where JavaScript provided by a website may induce the JavaScript JIT to create native code that manifests a speculative execution side channel vulnerability such as CVE-2017-5753. To help mitigate this, Microsoft Edge and Internet Explorer have been updated to reduce the precision of timers exposed by the web browser. This increases the difficulty of disclosing information with high bandwidth.

Applicability of mitigations

The complex nature of these issues makes it difficult to understand the relationship between mitigations, speculation techniques, and the attack scenarios to which they apply.

The legend for the tables that follow is:

Applicable Not applicable
Mitigation relationship to attack scenarios

The following table summarizes the relationship between attack scenarios and applicable mitigations.

Mitigation Tactic Mitigation Name Inter-VM Intra-OS Enclave Prevent speculation techniques Speculation barrier via execution serializing instruction Security domain CPU core isolation Indirect branch speculation barrier on demand and mode change Non-speculated or safely-speculated indirect branches Remove sensitive content from memory Hypervisor address space segregation Split user and kernel page tables (“KVA Shadow”) Remove observation channels Map guest memory as noncacheable in root extended page tables Do not share physical pages across guests Decrease browser timer precision
Mitigation relationship to variants

The following table summarizes the relationship between Spectre and Meltdown variants and applicable mitigations.

Mitigation Tactic Mitigation Name CVE-2017-5753 (variant 1) CVE-2017-5715 (variant 2) CVE-2017-5754 (variant 3) Prevent speculation techniques Speculation barrier via execution serializing instruction Security domain CPU core isolation Indirect branch speculation barrier on demand and mode change Non-speculated or safely-speculated indirect branches Remove sensitive content from memory Hypervisor address space segregation Split user and kernel page tables (“KVA Shadow”) Remove observation channels Map guest memory as noncacheable in root extended page tables Do not share physical pages across guests Decrease browser timer precision
Wrapping up

In this post, we described our approach toward mitigating a new hardware vulnerability class involving speculative execution side channels. We believe the mitigations described in this post offer strong protections for these vulnerabilities. Going forward, we recommend that the software industry view these issues as a new vulnerability class that may require software changes in order to help mitigate (e.g. like buffer overruns, type confusions, use after frees, and so on). We expect this new hardware vulnerability class to be the subject of further research as we’ve witnessed in the past with other vulnerability classes. Microsoft is committed to protecting our customers, and we will continue to work with our industry partners on mitigating speculative execution side channel vulnerabilities. To reinforce this commitment, we have launched the Speculative Execution Side Channel bounty program to encourage discovery and reporting of these vulnerabilities such that they can be fixed.

Matt Miller, Microsoft Security Response Center (MSRC)
Click to expand...

Source: Mitigating speculative execution side channel hardware vulnerabilities Defense

See also: Microsoft Announcing Speculative Execution Bounty Program Launch - Windows 10 Forums

Brink · Aug 14, 2018

Microsoft Announcing Speculative Execution Bounty Program Launch

Today, Microsoft is announcing the launch of a limited-time bounty program for speculative execution side channel vulnerabilities. This new class of vulnerabilities was disclosed in January 2018 and represented a major advancement in the research in this field. In recognition of that threat environment change, we are launching a bounty program to encourage research into the new class of vulnerability and the mitigations Microsoft has put in place to help mitigate this class of issues.

Quick Facts:

Bounty Duration: Open until December 31, 2018

Full Details: Speculative Execution Bounty Program

Bounty Terms: Standard terms and conditions apply

Bounty Tiers: (below)

Tier Payout (USD) Tier 1: New categories of speculative execution attacks Up to $250,000 Tier 2: Azure speculative execution mitigation bypass Up to $200,000 Tier 3: Windows speculative execution mitigation bypass Up to $200,000 Tier 4: Instance of a known speculative execution vulnerability (such as CVE-2017-5753) in Windows 10 or Microsoft Edge. This vulnerability must enable the disclosure of sensitive information across a trust boundary Up to $25,000
Speculative execution is truly a new class of vulnerabilities, and we expect that research is already underway exploring new attack methods. This bounty program is intended as a way to foster that research and the coordinated disclosure of vulnerabilities related to these issues. Tier 1 focuses on new categories of attacks involving speculative execution side channels. To help the community better understand what is currently known amongst the industry, our Security Research & Defense team has published blog with additional information. Tiers 2 and 3 focus on identifying possible bypasses for mitigations that have been added to Windows and Azure to defend against the attacks that have been identified. Tier 4 covers exploitable instances of CVE-2017-5753 or CVE-2017-5715 that may exist.

Speculative execution side channel vulnerabilities require an industry response. To that end, Microsoft will share, under the principles of coordinated vulnerability disclosure, the research disclosed to us under this program so that affected parties can collaborate on solutions to these vulnerabilities. Together with security researchers, we can build a more secure environment for customers.

Phillip Misner
Principal Security Group Manager
Microsoft Security Response Center
Click to expand...

Source: Speculative Execution Bounty Launch MSRC

Windows 10: Q3 2018 Intel Speculative Execution Side Channel Update

Q3 2018 Intel Speculative Execution Side Channel Update

Q3 2018 Intel Speculative Execution Side Channel Update

Q3 2018 Intel Speculative Execution Side Channel Update

Q3 2018 Intel Speculative Execution Side Channel Update - Similar Threads - 2018 Intel Speculative

Microsoft CVE-2017-5715: Guidance to mitigate speculative execution side-channel...

Manage Speculative Execution Settings Script for Windows

Windows Sandbox and Intel CPU Speculative side channel vulnerabilities

Surface Guidance for speculative execution side-channel vulnerability

New Speculative Execution Side-Channel Vunerability (Variant 4)

Microsoft Announcing Speculative Execution Bounty Program Launch

Mitigating speculative execution side-channel attacks in Edge and IE11

Mitigating speculative execution side channel hardware vulnerabilities

Windows Client Guidance against speculative execution vulnerabilities