SQL Server Guidance to Protect Against Meltdown and Spectre Attacks

[UPDATE: I’ve written a related post on this topic that you may find useful: How to Check if Your Database Server Is Protected Against Meltdown and Spectre]

You may have heard about the latest security issues with CPUs that affect Intel, AMD, and ARM processors. The attacks, named Meltdown and Spectre, were prompting DBAs around the globe to ask “how will this patch affect SQL Server performance”. The answer is simple: We don’t know for certain.

Today Microsoft released a KB article to provide guidance for SQL Server installations in response to the Meltdown and Spectre side-channel attacks. You should take the time to review that KB article. Here’s what Microsoft has to say about performance:

Microsoft continues to do performance evaluation on the patched binaries. However, at the time of publication, Microsoft has not yet validated SQL Server performance with all microcode patches, nor has it validated performance in all Linux environments. Customers are advised to evaluate the performance of their specific application when applying patches. Please validate the performance impact of enabling microcode changes before deploying into a production environment. Microsoft will update this section with more information when it is available.

Translation: We have no idea right now if your performance will be worse after patching.

 

Not everyone is at risk

But there is some good news, too. For example, if you are running on bare metal (no VMs), and you have no untrusted application logic on the server, and no untrusted SQL Server features (such as CLR), then you are likely fine for right now and there is no need to patch. The KB article lists out recommendations for users based upon scenarios such as bare metal, Azure VMs, and even for SQL Server on Linux.

And there is even more good news: these attacks only work if there is code, or malware, on your database server. It’s not as if the attackers can magically scrape the contents of your RAM through the CPU without having the code present on your system. This post does a great job of explaining the details about what is needed. That link also sheds some light onto who is likely to be using such attacks:

Even if an attacker did get access, they would get only “snippets” of data from the processor that could eventually be pieced together to reveal passwords or encryption keys, says cyber-security expert Alan Woodward, at the University of Surrey.

That means the incentive to use Meltdown or Spectre will at first probably be limited to those prepared to plan and carry out more complex attacks, rather than everyday cyber-criminals.

Translation: These attacks require more work on the backend to piece together the data they are scraping. Therefore, they are likely to attack systems where it is worth the risk.

 

SQL Server Features at risk for Meltdown and Spectre

This is the list of SQL Server features you should check for immediately. If you are using any one of these, you need to review the mitigation steps provided in the KB article:

– 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

I find the advice in the KB about migrating CLR code to T-SQL amusing. If you *could* do that, then you shouldn’t have been using CLR in the first place. But I digress.

Here’s my take on events this week: You shouldn’t be afraid to patch your systems. It’s 2018, and either you can deploy patches and updates with confidence, or you are doing it wrong.

Take the time this week to review your deployment process. Looks for ways to improve how you roll out patches. Embrace the use of automation to build a test environment, apply patches, and verify workload performance.

Take advantage of this situation to make your environment, and your team, better prepared for the next time.

Because there is always a next time.

[UPDATE: Allan Hirt (blog | @SQLHA) has a nice summary on his blog titled The No Good, Terrible Processor Flaw and SQL Server Deployments – Nearly Everything You Need To Know, you should go read this.]