SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 

Patching your SQL Servers - Meltdown and Spectre

The latest security issue with the name "Meltdown and Spectre" affecting Intel processors  was made public last week. This security issue affects a lot of systems and Operating Systems it is not a Microsoft specific issue. I think I read somewhere that ALL Mac devices are affected. Whilst details are relatively scares at time of writing Microsoft did release a blog post about how to best protect SQL Server…


In the post Microsoft talk about the different scenarios that you might be using to run SQL Server from bare metal through to a public "cloud" offering. I’ll refer you to the post to read the scenarios in detail. 

The table below shows the scenario number and highlights which scenario suggest patching you SQL Servers. This is taken directly from the Microsoft support article above and I suggest you refer to and read the Microsoft article above for any updates to the guidance.  

I wanted to use the table of scenarios in the post to highlight that every scenario bar one suggests patching your SQL Servers in some way. The one that doesn’t is scenario two where it refers to Azure where Microsoft have done this already.

Scenario 1
SQL Server runs on "bare metal" (no virtual machines)
Deploy updated OS and SQL patches after normal pre-production validation testing.
Scenario 2
SQL Server runs on a virtual machine in a public hosting environment.

For Azure: No VM image update necessary (see KB 4073235 for details). For other public hosts: refer to their guidance.
Scenario 3
SQL Server runs on a virtual machine in a private hosting environment.
Apply patch to host OS or isolate SQL Server on dedicated physical hardware.
Refer to Windows OS guidance on whether microcode changes should be enabled
Scenario 4
SQL Server runs on a physical or virtual machine and is not isolated from other application logic running on the same machine or is using extensibility interfaces in SQL Server with untrusted code.
Apply OS patches as described in Scenario 3.
Apply SQL Server patches, when available.
If running with untrusted code on the same machine, enable the microcode changes as described in the Windows OS guidance.
-or-

Restrict use of extensibility interfaces to block untrusted code from executing on the machine (see below).
Scenario 5
SQL Server 2017 runs on a Linux OS (independent of whether extensibility interfaces are being used).
Apply Linux OS patches.
Apply Linux SQL Server patches.
Consult with your Linux OS vendor about whether and how to enable the firmware changes

As an aside the performance advisory in the article that is worth is read too, I’ll quote directly form the article 

“...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.”
It may affect performance...

From my experience, patches are usually applied in reasonable time frame. Even if they can sometimes be a pain. Whilst most people will plan in patching for things like Patch Tuesdays– not everyone is as quick to upgrade their older systems. The older versions of SQL Server work fine and keep getting through the work. With plenty of other things to be getting on with upgrading the databases server or operating system do fall to the bottom of to do lists.

In the article, if you look at the “Supported Systems Affected” section you can see that is every version from SQL Server 2008 through to SQL Server 2017 on Linux if affected. 

I’m the process of running a survey on twitter asking what the oldest version of  SQL Server people have running in Production. The majority of people who have responded thus far have picked  SQL Server 2000 or SQL Server 2005 as their oldest version. As these versions of SQL Server are no longer supported, patches and fixes for the vulnerability won’t necessarily apply to these. This might be what you need to get business buy-in for upgrading your older versions of SQL Server to later and greater versions – as everyone can see the danger in the vulnerabilities remaining in the system for a long period of time.

If you need any help or advice about what is mentioned in the Microsoft article or if you want help with a SQL Server Upgrade to newer version of SQL Server check out our SQL Server consulting page and feel free to contact us, or book a free consultation we can have chat about your requirement

Comments

Leave a comment on the original post [www.gethynellis.com, opens in a new window]

Loading comments...