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.

Note To address the Spectre and Meltdown vulnerabilities as quickly as possible, delivery of these SQL Server updates was made initially to the Microsoft Download Center as the primary delivery model. Although these updates will be delivered through Microsoft Update in March, we recommend that affected customers install the update now without waiting for them to become available through Microsoft 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.

Although APS does not support the extensibility features from SQL Server listed in this bulletin, it is advised to install the Windows patches on the APS appliance. Enabling KVAS/IBP is not required.

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.

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)

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

Review security permissions to lock down scenarios in which CLR-based operations can be used. Limit CREATE ASSEMBLY, EXTERNAL ACCESS ASSEMBLY, and UNSAFE ASSEMBLY permission to the minimum set of users or code paths to disallow loading new assemblies into an existing, deployed application.

Review security permissions to lock down scenarios where external scripts can be used. Limit EXECUTE ANY EXTERNAL SCRIPT permission to the minimum set of users/code paths to disallow arbitrary scripts from being executed.

Using Linked Servers (sp_addlinkedserver)

Review installed OLEDB providers and consider removing any untrusted OLEDB providers from the machine. (Make sure that you do not remove OLEDB providers if they are used outside of SQL Server on the machine). An example on how to enumerate existing OLEDB providers is here: OleDbEnumerator.GetEnumerator Method (Type)

Review and remove any unneeded linked servers from SQL Server (sp_dropserver) to reduce the possibility of any untrusted code being executed within the sqlservr.exe process

Review security permissions to lock down ALTER ANY LINKED SERVER permission to the minimum number of users.

Review Linked Server Login/Credential mappings (sp_addlinkedsvrlogin/sp_droplinkedsvrlogin) to limit who can execute operations over linked servers to the minimum set of users/scenarios.

Using Extended Stored Procedures (sp_addextendedproc)

As Extended Stored Procedures are deprecated, remove all uses of these and do not use them in production systems.

Using xp_cmdshell to invoke binaries from SQL Server

This feature is off by default. Review and restrict all use of xp_cmdshell to invoke untrusted binaries. You can control access to this endpoint via sp_configure, as described here:

This feature is off by default. COM objects being invoked through sp_OACreate execute code installed on the server. Review any such calls for untrusted binaries. You can check the settings through sp_configure, as decribed here: