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 including Intel, AMD, and ARM.
Note this issue will affect other systems such as Android, Chrome, iOS, MacOS, so we advise customers to seek out 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 details.
Microsoft has not received any information to indicate that these vulnerabilities have been used to attack customers at this time. Microsoft continues working closely with industry partners including chip makers, hardware OEMs, and app vendors to protect customers. To get all available protections, hardware/firmware and software updates are required. This includes microcode from device OEMs and in some cases updates to AV software as well.
More information about the vulnerabilities can be found here: Microsoft Security Advisory ADV180002. General guidance for mitigating this class of vulnerability can be found here: Guidance for mitigating speculative execution side-channel vulnerabilities
Supported SQL Server versions impacted
The following versions are impacted when running on x86 and x64 processor systems:
- SQL Server 2008
- SQL Server 2008R2
- SQL Server 2012
- SQL Server 2014
- SQL Server 2016
- SQL Server 2017
IA64 (SQL Server 2008) is not believed to be impacted. Microsoft Analytic Platform Service (APS) is based on SQL Server 2014 or SQL Server 2016, but is not specifically impacted. Some general guidance for APS is listed later in this article.
The following table outlines what customers should do, depending on the environment SQL Server is running in and what functionality is being used. Microsoft recommends customers deploy fixes using normal procedures to validate new binaries before deploying to production environments.
Azure SQL Database and Data Warehouse
No action required (see here for details).
SQL Server is run on a physical machine or virtual machine
AND none of the following conditions are true:
Microsoft recommends installing all OS updates and applying SQL Server patches (see below). This protects against CVE 2017-5753.
Enabling Kernel Virtual Address Shadowing (KVAS) and Indirect Branch Prediction mitigation hardware support (IBP) are not required. (see below).
SQL Server is run in a physical or virtual machine
AND Another application which executes potentially hostile code is co-hosted on the same machine
AND/OR SQL Server extensibility interfaces are being used with untrusted code (see below for list)
Install all OS updates
Apply SQL Server patches (see below). This protects against CVE 2017-5753.
Enabling Kernel Virtual Address Shadowing (KVAS) is strongly recommended (see below). This protects against CVE 2017-5754.
Enabling Indirect Branch Prediction mitigation hardware support (IBP) is strongly recommended (see below). This protects against CVE 2017-5715
SQL Server is run on Linux OS.
Apply Linux OS updates from your distribution provider.
Apply Linux SQL Server patches (see below). This protects against CVE 2017-5753.
See below for guidance on whether to enable Linux Kernel Page Table Isolation (KPTI) and IBP (CVEs CVE 2017-5754 and CVE 2017-5715).
Analytics Platform System (APS)
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.
Customers are advised to evaluate the performance of their specific application when applying patches.
Microsoft advises all customers to install updated versions of SQL Server and Windows. This should have negligible to minimal performance impact to existing applications based on Microsoft testing of SQL workloads, however, we recommend that you validate before deploying to a production environment.
Microsoft has measured the impact 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 validate the performance impact of enabling these features before deploying into a production environment. If the performance impact of enabling these features is too high for an existing application, customers can consider whether isolating SQL Server from untrusted code running on the same machine is a better mitigation for their application.
More information on performance impact 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) & 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 is run on many environments: physical machines, VMs in public and private cloud environments, on Linux and Windows OS. Regardless of the environment, it is on a machine or VM. Call this the security boundary.
If all code in the boundary has access to all data in that boundary, then 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 running untrusted code.
To protect against untrusted code in a multi-tenant boundary, either
1. Remove the untrusted code. For details on how to do this for SQL Server extensibility mechanisms, see below. For removing untrusted code from other applications in the same boundary, application-specific changes are usually required, eg separating into two VMs.
2. Turn on KVAS/KPTI. This will have a performance impact, see above for details.
For more details on how to enable KVAS for Windows, see KB4072698. For details on how to enable KPTI on Linux, consult with your operating system's distributor.
An example of a scenario where KVAS/KPTI is strongly recommended:
An on-premises physical machine hosting 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/KPTI both to protect against disclosure of data within the sqlservr.exe process and to protect against disclosure of data within OS kernel memory.
Note Just because an extensibility mechanism within SQL Server is being used, that does not automatically make it unsafe. These mechanisms can be used safely within SQL Server as long as each dependency is understood and trusted by the customer. Furthermore, there are other products built on top of SQL that may require extensibility mechanisms to work properly. For example, a packaged application built on top of SQL Server may require a linked server or CLR stored procedure to function properly.
Microsoft does not recommending you remove these as part of the mitigation. Instead, review each use to determine if this code is understood and trusted as the initial action. This guidance is provided to help customers determine if they are in a situation where they need to enable KVAS as this has larger 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 above instructions for enabling KVAS on Windows will also enable IBP. However, IBP also requires a firmware update from your hardware manufacturer. In addition to the instructions in KB4072698, which enable protection in Windows, customers need to obtain and install updates from their hardware manufacturer.
An example of a scenario where IBP is strongly recommended:
In situations where IBP hardware support is not present, Microsoft recommends separating untrusted processes and trusted process onto different physical or virtual machines.
Linux Users: Contact your operating system's distributor for information about protecting against Variant 2 (CVE 2017-5715)
Available SQL Patches
At the time of publication, the following patched SQL Server builds are available for download:
4057122 Description of the security update for SQL Server 2017 GDR: January 3, 2018
4058562 Description of the security update for SQL Server 2017 RTM CU3: January 3, 2018
4058561 Description of the security update for SQL Server 2016 SP1 CU7: January 3, 2018
4057118 Description of the security update for SQL Server 2016 GDR SP1: January 3, 2018
4058559 Description of the security update for SQL Server 2016 CU: January 6, 2018
4058560 Description of the security update for SQL Server 2016 GDR: January 6, 2018
4057117 Description of the security update for SQL Server 2014 SP2 CU10: January 16, 2018
4057120 Description of the security update for SQL Server 2014 SP2 GDR: January 16, 2018
4057116 Description of the security update for SQL Server 2012 SP4 GDR: January 12, 2018
4057115 Description of the security update for SQL Server 2012 SP3 GDR: January, 2018
4057121 Description of the security update for SQL Server 2012 SP3 CU: January, 2018
4057114 Description of the security update for SQL Server 2008 SP4 GDR: January 6, 2018
4057113 Description of the security update for SQL Server 2008 R2 SP3 GDR: January 6, 2018
This document will be updated when additional patched builds are available.
For Windows OS Builds, refer to the following guidance for the latest on available Windows builds:
For Linux builds, contact the Linux vendor to find the latest patched builds for your specific Linux distribution.
Untrusted SQL Server extensibility mechanisms
SQL Server contains many extensibility features/mechanisms. Most of these mechanisms are disabled by default, but Microsoft advises customers to review each production instance for extensibility feature use. Microsoft recommends that each of these features be restricted to the minimum set of binaries and that customers should restrict access to avoid arbitrary code running on the same machines as SQL Server. Customers are advised to determine whether to trust each binary and should disable/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 machine as SQL Server
- SQL Agent extensibility points running on the same physical machine 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 via sp_OACreate)
- Programs executed via xp_cmdshell
Mitigations to take if using untrusted code in SQL Server:
Running SQL Server with CLR enabled (sp_configure ‘clr enabled', 1)
Running R/Python external scripts from within SQL Server (sp_configure 'external scripts enabled', 1)
Using Linked Servers (sp_addlinkedserver)
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 outlined here:
Using COM Objects via sp_OACreate
This feature is off by default. COM objects being invoked via sp_OACreate execute code installed on the server. Review any such calls for untrusted binaries. You can check the settings via sp_configure as outlined here: