Protect SQL Server from attacks on Spectre and Meltdown side-channel vulnerabilities

Applies to: Microsoft SQL Server

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

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.

Available SQL Patches

At the time of publication, the following updated SQL Server builds are available for download:

Servicing release

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 updated builds are available.

Note All subsequent SQL Server 2014, SQL Server 2016, and SQL Server 2017 Service Packs and Cumulative Updates will contain the fixes. For example, SQL Server 2016 SP2 already contains the Spectre and Meltdown  fixes.

For Windows builds, refer to the following guidance for the latest information about available Windows builds:

Windows Server Guidance

For Linux builds, contact your Linux vendor to find the latest updated builds for your specific Linux distribution.

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.

Scenario number

Scenario description

Priority recommendations

1

Azure SQL Database and Data Warehouse

No action required (see here for details).

2

SQL Server is run on a physical computer or virtual machine

AND none of the following conditions are true:

  • Another application that executes potentially hostile code is co-hosted on the same computer
  • SQL Server extensibility interfaces are being used with untrusted code (see below for list)

 

Microsoft recommends installing all OS updates. 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 patches should be installed as part of normal patching policy at next scheduled update window.

3

SQL Server is run on a physical computer or virtual machine

AND Another application that executes potentially hostile code is co-hosted on the same computer

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

4

SQL Server is run on a physical computer

AND Another application that executes potentially hostile code is not co-hosted on the same computer

AND SQL Server extensibility interfaces ARE being used to execute TRUSTED code.

Examples: 

  • CLR assemblies that have been reviewed/approved for use in production 
  • Linked servers that you trust running vetted queries that you trust

Non-Examples:

  • Arbitrary R/Python Scripts downloaded from the Internet
  • Untrusted CLR binaries from a third party

Install all OS updates

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 patches should be installed as part of normal patching policy at next scheduled update window.

5

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).

6

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.

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)

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:

Scenario/Use case

Mitigations or suggested steps

Running SQL Server with CLR enabled (sp_configure ‘clr enabled', 1)

  1. If possible, disable CLR if it is not required in your application to reduce the risk of any untrusted code being loaded into SQL Server
  1. (SQL Server 2017+) If CLR is still needed in your application, enable only specific assemblies to be loaded using the “CLR Strict Security” feature (https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/clr-strict-security) using sys.sp_add_trusted_assembly (https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-add-trusted-assembly-transact-sql)
  1. Consider whether CLR code can be migrated to T-SQL equivalent code
  1. 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.

Running R/Python external scripts from within SQL Server (sp_configure 'external scripts enabled', 1)

  1. If possible, disable the external scripts capability if not needed in your application to reduce attack surface area.
  1. (SQL Server 2017+) If possible, migrate external scripts doing scoring to use the native scoring feature instead (https://docs.microsoft.com/en-us/sql/advanced-analytics/sql-native-scoring)
  1. 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)

  1. 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)
  1. 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
  1. Review security permissions to lock down ALTER ANY LINKED SERVER permission to the minimum number of users.
  1. 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:

 

Using COM Objects via sp_OACreate

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: