More information on the Patch Tuesday updates for SQL Server
Last week, Microsoft released a series of patches for all supported versions of SQL Server (from SQL Server 2005 SP3 all the way to SQL Server 2008 R2). The reason for the patch against SQL Server installations is largely a client-side issue with the XML viewer application, and for SQL Server specifically, the exploit is limited to potential information disclosure. A very easy way to avoid exposure to this exploit is simply to never open a file with the .disco extension (these files are likely already blocked by your e-mail system, but you can never be too careful). Still, Microsoft's recommendation is to patch all systems. You can read more about your course of action, depending on your current build, in my previous blog post.
After the patches were released, some pertinent questions came up, and I sought answers from an internal source — after my questions during a security webinar, which you can now view online, proved useless.
- Why is sqlservr.exe affected at all?
As mentioned, this is a patch specifically for an application that is part of the client tools, so it made little sense to me why sqlservr.exe (and @@VERSION) would be updated. My answer from the patch team is that, while sqlservr.exe has not updated since the previous Cumulative Update release for each branch, some of its dependencies were updated, so the build number was increased for consistency with other files in the branch. - What other fixes are included in the GDR and QFE updates, aside from the XML viewer fix?
This question was raised because the build number increased significantly in some cases – for example, in SQL Server 2005 SP4, the build number on top of Cumulative Update #2 (9.0.5266) jumped to 9.0.5292 once the update was applied. This caused concern amongst some customers, who expect from such a delta that they have other regression testing to do. The reason cited here is that only the security bulletin update is in the GDR and QFE updates, and that the build number gap is intentional, so that the fix may be applied to all customers. If I'm reading between the lines, that tells me that either (a) some customers had interim (non-public) hotfixes after the latest CU, or (b) they are leaving room so that customers at the previous CU can still apply hotfixes even if they don't apply the security bulletin update. I have no way to confirm either of those hypotheses, but right now the word from Microsoft is that there should be no further regression testing required.
That said, for build number continuity, the packages *do* contain the previous public cumulative update. So, for example, both the GDR and QFE update for SQL Server 2008 R2 contains Cumulative Update #7 and the fix itself. So "which fixes are in the package" depend on what build you are at before you apply the security update. If you are not at the most recent CU, then you will benefit from other fixes (and may have further regression testing to perform) — but these are not due to the security update itself.
- Will the security fixes be included in the next CU for each branch?
Since the next cumulative update for SQL Server 2008 R2 is due in the near future, and since we have learned from experiences with applying service packs that don't always include the fixes from the most recent cumulative update (even though the build numbers would imply that they are included), I wanted to know if this set of fixes has made it into all of the cumulative update branches. The answer is that, yes, the next cumulative update for each branch will include this security fix (though those updates will likely have even higher build numbers than the security update for each branch). I take it by extension that the upcoming Service Pack 1 for SQL Server 2008 R2 will also include this fix, but I did not ask that question explicitly, so if you are currently running the CTP of Service Pack 1 (10.50.2418 or 10.50.2425), I cannot honestly tell you how long you will be waiting for this fix (see the above comment about being careful with .disco files).
In addition to these questions, I'm also seeing some reports of bad behavior on systems where automatic updates are applied or where certain cumulative updates were already in place. Please see the following items and use caution when applying this update:
Now, I am running Windows 7 x64, and I am only using Windows Update (I have never turned on Microsoft Update, and didn't find much reason to, since I don't run Windows-based Office applications – I didn't realize that Microsoft Update covered SQL Server products also). So the patch was never offered to me; I applied it manually, and did not experience these issues. If you have either of these problems (or others that haven't been brought to my attention), hopefully I will have some information for you soon.
Also please see this blog post from PSS:
http://blogs.msdn.com/b/psssql/archive/2011/06/28/sql-server-2008-r2-does-not-start-when-applying-certain-hotfix-updates.aspx
This patch will put your sql server in script upgrade mode. Please be aware of the downtime if you have a large amount of databases. This happened on my sql 2008 sp2 cluster
Glenn, the problem with doing that is that it just puts the SP further behind, and then another CU is always in the works. You have to draw the line somewhere, do the bullet-proof testing that an SP requires, and commit catch up in the next CU. I have the same wish you do, but I don't think there is an easy answer.
Good coverage of this issue, Aaron. I wonder when SQL Server 2008 R2 SP1 will be available (in gold, not CTP), and whether it will be one CU behind the RTM branch (which is typically the case) when it first comes out.
It would be nice if Microsoft would synchronize SQL Server 2008 R2 RTM CU8 and SQL Server 2008 R2 SP1 (so that the gold version of SP1 had everything that was in RTM CU8). This would be a lot less confusing for people…