Summary
Microsoft is aware of a new publicly disclosed class of vulnerabilities that are known as “speculative execution side-channel attacks.” These vulnerabilities affect many modern processors and operating systems. This includes chipsets from Intel, AMD, and ARM.
We have not yet received any information to indicate that these vulnerabilities have been used to attack customers. We continue to work closely with industry partners to protect customers. This includes chip makers, hardware OEMs, and application vendors. To get all available protection, hardware or firmware and software updates are required. This includes microcode from device OEMs and, in some cases, updates to antivirus software. We have released several updates to help mitigate these vulnerabilities. More information about the vulnerabilities can be found in Microsoft Security Advisory ADV180002. For general guidance, also see Guidance for mitigating speculative execution side-channel vulnerabilities. We have also taken action to help secure our cloud services. See the following sections for more details.
Affected Exchange Server versions
Because these are hardware-level attacks that target x64-based and x86-based processor systems, all supported versions of Microsoft Exchange Server are affected by this issue.
Recommendations
The following table describes the recommended actions for Exchange Server customers. There are no specific Exchange updates that are required currently. However, we recommend that customers always run the latest Exchange Server cumulative update and any required security updates. We recommend that you deploy fixes by using your ususal procedures to validate new binaries before you deploy them to production environments.
|
Scenario |
Description |
Recommendations |
|
1 |
Exchange Server is run on bare metal (no virtual machines) and no other untrusted application logic (application tier) is run on the same bare metal machine.
|
Apply all system and Exchange Server updates after your usual pre-production validation testing. Enabling Kernel Virtual Address Shadowing (KVAS) is not required (see the related section later in this article). |
|
2 |
Exchange Server is run on a virtual machine in a public hosting environment (cloud). |
For Azure: Microsoft has posted details about mitigation efforts for Azure (see KB 4073235 for detailed information). For other cloud providers: Refer to their guidance. We recommend installing all OS updates on the guest virtual machine (VM.) Refer to guidance later in this article about whether to enable KVAS. |
|
3 |
Exchange Server is run on a virtual machine in a private hosting environment. |
Refer to the hypervisor security documentation for security best practices. See KB 4072698 for Windows Server and Hyper-V. We recommend installing all OS updates on the guest VM. Refer to later guidance in this article about whether to enable KVAS. |
|
4 |
Exchange Server is run on a physical or virtual machine and is not isolated from other application logic that is running on the same system.
|
We recommend installing all OS updates. Refer to the guidance later in this article article about whether to enable KVAS. |
Performance Advisory
We advise all customers to evaluate the performance of your specific environment when you apply updates.
Solutions that are provided by Microsoft for the types of vulnerabilities that are discussed here will use software-based mechanisms to protect against cross process access to data. We advise all customers to install updated versions of Exchange Server and Windows. This should have a minimal performance effect, based on Microsoft testing of Exchange workloads.
We have measured the effect of Kernel Virtual Address Shadowing (KVAS) on various workloads. We have found that some workloads experience a significant decrease in performance. Exchange Server is one of those workloads that may experience a significant decrease if KVAS is enabled. Servers that show high CPU usage or high I/O usage patterns are expected to show the largest effect. We highly recommend that you first evaluate the performance effect of enabling KVAS by running tests in a lab that represents your production needs before you deploy into a production environment. If the performance effect of enabling KVAS is too high, consider whether isolating Exchange Server from untrusted code that is running on the same system is a better mitigation for the application.
In addition to KVAS, information about the performance effect from Branch Target Injection mitigation hardware support (IBC) is detailed here. A server that is running Exchange Server and that has an IBC solution deployed to it may experience a significant decrease in performance if IBC is enabled.
We anticipate that hardware suppliers will offer updates to their products in the form of microcode updates. Our experience with Exchange indicates that microcode updates will increase the performance drop. The extent to which this occurs is highly dependent on the components and the design of the system on which they are applied. We believe that no single solution, whether software-based or hardware-based, is sufficient to address this type of vulnerability alone. We encourage you to evaluate the performance of all updates to account for variability in system design and performance before you put them into production. The Exchange team is not planning to update the sizing calculator that is used by customers to account for performance differences currently. The calculations provided by this tool will not take into account any changes in performance that are related to fixes for these issues. We will continue to evaluate this tool and the adjustments that we believe may be required, based on our own usage and that of customers.
We will update this section as more information becomes available.
Enabling Kernel Virtual Address Shadowing
Exchange Server is run in many environments, including physical systems, VMs in public and private cloud environments, and Windows operating systems. Regardless of the environment, the program is located on a physical system or a VM. This environment, whether physical or virtual, is known as the security boundary.
If all code within the boundary has access to all data within that boundary, no action is required. If this is not the case, the boundary is said to be multi-tenant. The vulnerabilities that have been found make it possible for any code that is running in any process within that boundary to read any other data within that boundary. This is true even under reduced permissions. If any process in the boundary is running untrusted code, that process could use these vulnerabilities to read data from other processes.
To protect against untrusted code in a multi-tenant boundary, do either of the following:
-
Remove the untrusted code.
-
Turn on KVAS to protect against process-to-process reads. This will have a performance effect. See the earlier sections in this article for detailed information.
For more information about how to enable KVAS for Windows, see KB 4072698.
Example scenarios (KVAS is strongly recommended)
Scenario 1
An Azure VM runs a service in which untrusted users can submit JavaScript code that is run by having limited permissions. On the same VM, Exchange Server is running and managing data that should not be accessible to those untrusted users. In this situation, KVAS is required to protect against disclosure between the two entities.
Scenario 2
An on-premises physical system that hosts Exchange Server can run untrusted third-party scripts or executables. It is necessary to enable KVAS to protect against the disclosure of Exchange data to the script or executable.
Note Just because an extensibility mechanism within Exchange Server is being used, that does not automatically make it unsafe. These mechanisms can be used safely within Exchange Server as long as each dependency is understood and trusted. Additionally, there are other products that are built on Exchange Server that may require extensibility mechanisms to work correctly. Instead, as your first action, review each use to determine whether the code is understood and trusted. This guidance is provided to help customers determine whether they have to enable KVAS because of larger performance implications.
Enabling Branch Target Injection Mitigation (IBC) Hardware Support
IBC mitigates against CVE 2017-5715, also known as one half of Spectre or “variant 2” in the GPZ disclosure.
These instructions for enabling KVAS on Windows can also enable IBC. However, IBC also requires a firmware update from your hardware manufacturer. In addition to the instructions in KB 4072698 to enable protection in Windows, customers have to obtain and install updates from their hardware manufacturer.
Example scenario (IBC is strongly recommended)
Scenario 1
In an on-premises physical system that is hosting Exchange Server, untrusted users are allowed to upload and run arbitrary JavaScript code. In this scenario, we strongly recommended IBC to protect against process-to-process information disclosure.
In situations in which IBC hardware support is not present, we recommend that you separate untrusted processes and trusted process onto different physical or virtual machines.
Untrusted Exchange Server Extensibility Mechanisms
Exchange Server includes extensibility features and mechanisms. Many of these are based upon APIs that do not allow untrusted code to run on the server that is running Exchange Server. Transport Agents and Exchange Management Shell could allow untrusted code to run on a server that is running Exchange Server in certain situations. In all cases, except for Transport Agents, extensibility features require authentication before they can be used. We recommend that you use extensibility features that are restricted to the minimum set of binaries wherever applicable. We also recommend that customers restrict server access to avoid having arbitrary code run on the same systems as Exchange Server. We advise you to determine whether to trust each binary. You should disable or remove untrusted binaries. You should also make sure that management interfaces are not exposed on the Internet.
Any third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.
