KB4073225 - SQL Server guidance to protect against Spectre, Meltdown and Micro-architectural Data Sampling vulnerabilities

Summary

Microsoft is aware of a new publicly disclosed class of vulnerabilities referred to as “speculative execution side-channel attacks” that affect many modern processors and operating systems. This includes Intel, AMD, and ARM.

Note This issue also affects other systems, such as Android, Chrome, iOS, and MacOS. Therefore, we advise customers to seek guidance from those vendors.

Microsoft has released several updates to help mitigate these vulnerabilities. We have also taken action to secure our cloud services. See the following sections for more information.

Microsoft has not received any information to indicate that these vulnerabilities have been used to attack customers at this time. Microsoft continues to work closely together with industry partners, including chip makers, hardware OEMs, and application vendors, to protect customers. To get all available protections, hardware or firmware and software updates are required. This includes microcode from device OEMs and, in some cases, updates to antivirus software.

For more information about the vulnerabilities, see Microsoft Security Advisory ADV180002. For general guidance to mitigate this class of vulnerability, see Guidance for mitigating speculative execution side-channel vulnerabilities

Microsoft published ADV190013 - Microsoft Guidance to Mitigate Microarchitectural Data Sampling Vulnerabilities in May 2019. SQL Server does not have any specific security patches for the issue described in ADV190013. You can find guidance for environments affected by ADV190013 in the Recommendations section of this article. Please note that this advisory only applies to Intel Processors.

How to obtain and install the update

This update is also available through Windows Server Update Services (WSUS), or the Microsoft Update Catalog website.

Note: This update will not be downloaded and installed automatically via Windows Update.

Supported SQL Server versions that are affected

Microsoft recommends that all customers install the SQL Server updates (listed below) as part of their regular patching cycle.  Customers that run SQL Server in a secure environment where extensibility points are blocked and all third party code running on the same server is trusted and approved should be unaffected by this issue.

The following versions of SQL Server have available updates when they run on x86 and x64 processor systems:

• SQL Server 2008

• SQL Server 2008R2

• SQL Server 2012

• SQL Server 2014

• SQL Server 2016

• SQL Server 2017

We do not believe that IA64 (Microsoft SQL Server 2008) is affected. Microsoft Analytic Platform Service (APS) is based on Microsoft SQL Server 2014 or Microsoft SQL Server 2016, but it is not specifically affected. Some general guidance for APS is listed later in this article.

Recommendations

The following table outlines what customers should do, depending on the environment in which SQL Server is running and what functionality is being used. Microsoft recommends that you deploy fixes by using your usual procedures to test new binaries before you deploy them to production environments.

Performance Advisory

Customers are advised to evaluate the performance of their specific application when they applying updates.

Microsoft advises all customers to install updated versions of SQL Server and Windows. This should have a negligible-to-minimal performance effect on existing applications, based on Microsoft testing of SQL workloads. However, we recommend that you test all updates before you deploy them to a production environment.

Microsoft has measured the effect of Kernel Virtual Address Shadowing (KVAS), Kernel Page Table Indirection (KPTI) and Indirect Branch Prediction mitigation (IBP) on various SQL workloads in various environments and found some workloads with significant degradation. We recommend that you test the performance effect of enabling these features before you deploy them in a production environment. If the performance effect of enabling these features is too high for an existing application, you can consider whether isolating SQL Server from untrusted code running on the same computer is a better mitigation for your application.

More information on performance effect from Indirect Branch Prediction mitigation hardware support (IBP) is detailed here.

Microsoft will update this section with more information when it is available.

Enabling Kernel Virtual Address Shadowing (KVAS in Windows) and Kernel Page Table Indirection (KPTI on Linux)

KVAS and KPTI mitigate against CVE 2017-5754, also known as “Meltdown” or “variant 3” in the GPZ disclosure.

SQL Server is run on many environments: physical computers, VMs in public and private cloud environments, on Linux and Windows systems. Regardless of the environment, the program is run on a computer or VM. Call this the security boundary.

If all code in the boundary has access to all data in that boundary, no action is necessary. If this is not the case, the boundary is said to be multi-tenant. The vulnerabilities found make it possible for any code, even with reduced permissions, running in any process in that boundary, to read any other data within that boundary. If there is any process in the boundary running untrusted code, it could use these vulnerabilities to read data from other processes. This untrusted code could be untrusted code using SQL Server extensibility mechanisms or other processes in the boundary that are running untrusted code.

To protect against untrusted code in a multi-tenant boundary, use either of the following methods

• Remove the untrusted code. For more information about how to do this for SQL Server extensibility mechanisms, see below. To remove untrusted code from other applications in the same boundary, application-specific changes are usually required. For example, separating into two VMs.

• Turn on KVAS or KPTI. This will have a performance effect. For more information, as described earlier in this article.

For more information about how to enable KVAS for Windows, see KB4072698. For more information about how to enable KPTI on Linux, consult with your operating system distributor.

An example of a scenario in which KVAS or KPTI is strongly recommended

An on-premises physical computer that hosts SQL Server as a non-system administrator account allows customers to submit arbitrary R scripts to run through SQL Server (which uses secondary processes to run these scripts outside of sqlservr.exe). It is necessary to enable KVAS and KPTI both to protect against disclosure of data within the Sqlservr.exe process and to protect against disclosure of data within the system kernel memory.

Note An extensibility mechanism within SQL Server is not automatically considered unsafe just because it is being used. These mechanisms can be used safely within SQL Server as long as each dependency is understood and trusted by the customer. Also, there are other products that are built on top of SQL that may require extensibility mechanisms to work correctly. For example, a packaged application that is built on top of SQL Server may require a linked server or CLR stored procedure in order to function correctly.

Microsoft does not recommend that you remove these as part of the mitigation. Instead, review each use to determine whether this code is understood and trusted as the initial action. This guidance is provided to help customers determine whether they are in a situation in which they have to enable KVAS. This is because this action has significant performance implications.

Enabling Indirect Branch Prediction mitigation (IBP) hardware support

IBP mitigates against CVE 2017-5715, also known as one half of Spectre or “variant 2” in the GPZ disclosure.

The instructions in this article to enable KVAS on Windows also enables IBP. However, IBP also requires a firmware update from your hardware manufacturer. In addition to the instructions in KB4072698 to enable protection in Windows, customers have to obtain and install updates from their hardware manufacturer.

An example of a scenario in which IBP is strongly recommended

An on-premises physical computer is hosting SQL Server alongside an application that allows untrusted users to upload and execute arbitrary JavaScript code. Assuming that that there exists confidential data in the SQL database, IBP is strongly recommended as a measure to protect against process-to-process information disclosure.

In situations in which IBP hardware support is not present, Microsoft recommends separating untrusted processes and trusted process onto different physical computers or virtual machines.

Linux users: Contact your operating system distributor for information about how to protect against Variant 2 (CVE 2017-5715).

An example of a scenario in which mitigation for Microarchitectural Data Sampling Vulnerabilities is strongly recommended

Consider an example where an on-premises server is running two instances of SQL Server hosting two different business applications on two different virtual machines on the same physical host. Assume that these two business applications should not be able to read data stored across the SQL Server instances. An attacker who successfully exploited these vulnerabilities may be able to read privileged data across trust boundaries by using untrusted code running on the machine as a separate process or untrusted code executed using a SQL Server extensibility mechanism (see section below for extensibility options in SQL Server). In shared resource environments (such as exists in some cloud services configurations), these vulnerabilities could allow one virtual machine to improperly access information from another. In non-browsing scenarios on standalone systems, an attacker would need prior access to the system or an ability to run a specially crafted application on the target system to leverage these vulnerabilities.

Untrusted SQL Server extensibility mechanisms

SQL Server contains many extensibility features and mechanisms. Most of these mechanisms are disabled by default. However, we advise customers to review each production instance for extensibility feature use. We recommend that each of these features be restricted to the minimum set of binaries, and that customers restrict access to prevent arbitrary code from running on the same computer as SQL Server. We advise customers to determine whether to trust each binary,  and to disable or remove untrusted binaries.

• SQL CLR assemblies

• R and Python packages running through the external scripts mechanism or run from the standalone R/Machine Learning studio on the same physical computer as SQL Server

• SQL Agent extensibility points running on the same physical computer as SQL Server (ActiveX scripts)

• Non-Microsoft OLE DB providers used in Linked Servers

• Non-Microsoft Extended Stored Procedures

• COM objects executed within the server (accessed through sp_OACreate)

• Programs executed through xp_cmdshell

Mitigations to take if using untrusted code in SQL Server: