Message-ID: <ILEPILDHBOLAHHEIMALBOEOMFAAA.jasonc@science.org>
Date: Sat, 15 Mar 2003 23:19:59 -1000
From: "Jason Coombs" <jasonc@...ence.org>
To: <bugtraq@...urityfocus.com>
Cc: <full-disclosure@...ts.netsys.com>
Subject: A response to Bruce Schneier on MS patch management and Sapphire



-----Original Message-----
From: Jason Coombs [mailto:jasonc@...ence.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@...ence.org

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists