-----Original Message----- From: Jason Coombs [mailto:jasonc@science.org] Sent: Sunday, February 16, 2003 10:31 AM To: Bruce Schneier Subject: RE: CRYPTO-GRAM, February 15, 2003 Aloha, Bruce. This is in response to your Crypto-Gram discussion of the Sapphire/SQL Slammer worm that struck Microsoft SQL Server in January. Microsoft Baseline Security Analyzer (MBSA) and Microsoft's version of HFNetChk both failed to detect the presence of the well-known vulnerability in SQL Server exploited by Sapphire, which is one of the reasons so many admins (both inside and outside MS) had failed to install the necessary hotfix. MBSA and HFNetChk are Microsoft's official patch status verification tools meant to be used by all owners of Windows server boxes. Both of these tools rely on an XML file called mssecure.xml (distributed either as raw text/XML or as a digitally-signed cabinet file (mssecure.cab) from well-known distribution points hard-coded into the tools. The mssecure.xml file is assembled by a human being from an arbitrary human-edited subset of all hotfixes, service packs, and security bulletins released by Microsoft. The two primary sources are Shavlik Technologies (the third-party developer who created these tools working under contract) and Microsoft. Until recently, HFNetChk was designed to retrieve Microsoft's version by default. The latest version of HFNetChk now retrieves Shavlik's version by default because Microsoft stopped updating mssecure.xml on a regular basis and with the attention to detail required for this whole system of patch status verification to work properly. mssecure.cab published by Shavlik Technologies: http://xml.shavlik.com/mssecure.cab mssecure.xml from Shavlik Technologies: https://xml.shavlik.com/mssecure.xml Microsoft version of mssecure.cab: http://download.microsoft.com/download/xml/security/1.0/nt5/en-us/mssecure.c ab mssecure.xml from Microsoft: https://www.microsoft.com/technet/security/search/mssecure.xml Microsoft?s international customer support groups publish their own language localized version of mssecure.cab - the Japanese version is here: http://download.microsoft.com/download/xml/security/1.0/NT5/JA/mssecure.cab The Shavlik Technologies version of mssecure.xml contained the necessary information about the vulnerable SQL Server binary (ssnetlib.dll) so any user of HFNetChk who relied on Shavlik's XML file was warned months in advance that a hotfix was needed to patch this file. Unfortunately, the version of HFNetChk distributed by Microsoft (version 3.32) relied on Microsoft's XML file by default. Only admins who downloaded the updated HFNetChk (version 3.86) directly from Shavlik Technologies had a tool that automatically relied on Shavlik's XML file and could therefore detect the vulnerable ssnetlib.dll file and warn that it needed a hotfix during calendar year 2002. By January 25, 2003 when Sapphire struck, Microsoft's mssecure.xml file had been updated to include information about the vulnerability, so admins would have been given a couple weeks of advance notice if they relied on Microsoft's HFNetChk version 3.32 -- the problem is that Microsoft has stopped pushing HFNetChk and now directs everyone to MBSA. MBSA is set to run, by default, in "least-secure" scanning mode. There is a lesser-known tool shipped with MBSA called MBSA Command Line Interface (mbsacli.exe) and its usage instructions detail this default limitation of the MBSA GUI: "The MBSA V1.1 graphical interface default scan parameters are: /s 2 /nosum /baseline" where /s 2 /nosum /baseline have the following effect: /s 2 Suppress security update check notes and warnings. /baseline Check only for baseline security updates. /nosum Security update checks will not test file checksums. In addition to designing MBSA to avoid scanning for SQL Server vulnerabilities, failing to update mssecure.xml reliably and in a timely manner, deprecating HFNetChk by pushing the MBSA GUI as its preferred replacement, and hiding the details of the technical limitations and internal security assumptions made by design in Microsoft's security analysis tools, Microsoft pushes Windows Update (windowsupdate.com) as a safe and reliable way to keep Windows boxes up-to-date. Unfortunately, Windows Update isn't designed to supply or verify the presence of SQL Server hotfixes, either. None of Microsoft's own hotfix/patch status scanning tools designed to prove "baseline security" were able to help administrators avoid Sapphire. This entire scenario, this comedy of errors, illustrates the security risk created by any organization that pushes security around from department to department, passing the buck and hoping that somebody else will know how to deal with the problem. The result is a system so flawed that it borders on the absurd. Sincerely, Jason Coombs jasonc@science.org
