This post is part of our SQL Server security blog series, 30 SQL Server Security Checks in 30 Days. We’re publishing a new security check every day in the month of June. Visit our sp_CheckSecurity page to learn about our free SQL Server tool you can download and run to check your own server.
For many years, SQL Server updates were an odd mix of “Service Packs” (SPs) and “Cumulative Updates” (CUs) – which weren’t completely cumulative – with each release including some number of security updates, added features, and hotfixes. Deciding what and when to apply was all a bit of a guessing game, as discerning administrators had to decide which ones to apply and which ones to skip.
I’m eternally grateful we’ve have (completely) cumulative CUs since SQL Server 2017, but the CUs still aren’t the only updates. In fact, they may not even be the most important updates.
Starting in 2015, Microsoft released their first “Security Update” for versions of SQL Server, which addressed specific vulnerabilities related to hacking attacks. Other security updates have been released over the years as vulnerabilities have been discovered, but since 2018 these updates have been released with the vague name of “General Distribution Release” (GDRs). For SQL Server 2017 alone there have been 8 GDRs, so they have been plentiful.
Are these GDRs really important?
One interesting feature of GDRs is they will have a vulnerability rating that you can check to determine how quickly you should apply them. For example, a recent GDR for SQL Server 2022 (KB5036343) contained several security updates listed in the Summary.
…and that’s just part of the list, as there are nearly 40 vulnerabilty updates in this GDR! If you click on any of those links, you can see a vulnerability score on a scale of 1-10. Here’s the score for the first one, highlighted below.
A vulnerability score of 8.8 out 10 is pretty significant, so you probably want to read more about these vulnerabilities and schedule a time to update your SQL Server instance soon.
How do we know if any GDRs have been applied to our SQL Server instances?
The main way to tell is by checking the version, which is really easy.
SELECT @@VERSION;
You can then compare that version number on a site like SQL Server Builds or SQL Server Updates to determine the update level of your SQL Server instance.
Because of their heightened importance, Microsoft may even have applied these GDR automatically to your instance via Windows Updates, including them with other Windows-related security updates. Take a look in Windows Updates to see if you have “Get updates for other Microsoft products” enabled. If you do, it’s possible you are getting these updates automatically included with your Windows patching.
Regarding this setting, we definitely do NOT recommend enabling that feature for SQL Server updates. We’ve seen more than a few of these updates get applied and then SQL Server won’t restart. Since many organizations have updates applied automatically in the wee hours, this means that you could get awakened in the night about a SQL Server instance being down. Not fun.
How do these GDRs fit with CUs?
Cumulative updates are still cumulative, so the most recent CU for your instance will include all prior GDRs. However, GDRs are very specific, so Microsoft has made it possible for GDRs to be applied on their own without any dependencies on CUs. Why? Well, I suppose it’s because some organizations don’t have the time and resources to test all features and fixes of every CU, so they would rather you apply the GDR to update vulnerabilities than do nothing at all.
But here’s the rub: as previously noted, every SQL Server update, whether CU or GDR, has a version number to indicate it has been applied…but if you ONLY apply a GDR then the version won’t tell if any previous CUs have been applied. This can be a bit misleading if you haven’t been proactively applying CUs to your instance.
What does Straight Path recommend?
Because of the confusion that can be caused from applying GDRs without applying CUs, we recommend sticking to the timeline and manually applying all updates. That is, if possible, to apply CUs regularly. It’s not a bad idea to wait a few weeks before applying the most recent CU, since occasionally some CUs have nasty consequences and may even be pulled from release. But if you develop some sort of update cadence to regularly keep up to date with applying CUs, you don’t have to worry about having to quickly apply any GDRs to fix your SQL Server security vulnerabilities.
