Xato commentary on MS security bulletins

[".sozni" <sozni () XATO NET>]

***Elias: if you have not already approved the previous post, could you use
this one instead? - sozni



In light of some posts to several mailing lists recently, I must comment on
some of the issues we at xato have found with Microsoft and their security
bulletins.  Of course, this isn't just a Microsoft issue as these ideas
could equally apply to any vendor that consistently releases a number of
security advisories.  These are not critical issues but they things that
make the already difficult job of managing hotfixes so much more difficult.

Several months ago xato set out to simplify the management of hotfixes by
providing charts, timelines and additional detail and cross-references for
Microsoft security bulletins.  In doing so we encountered some frustrating
inconsistencies as well as some important issues that could easily be
overlooked without doing such in-depth research.

The biggest problem is that there is a great inconsistency in Microsoft's
hotfix procedures, possibly because they have no written policies to follow
when creating and managing security bulletins.  There is no doubt that many
servers are hacked simply because they did not keep up with their bulletins.
And there is also no doubt that it is often a confusing and difficult
process for an administrator to keep up with new bulletins (as well as
changes to old ones).

As I mentioned before, we have been developing a hotfixes reference site to
help reduce this problem and in doing so have noticed a number of problems
in the way Microsoft (and again, probably many other companies) manage their
hotfixes.  Here are the main problem areas we have noticed:

Change Control
--------------
We feel that change control is a very important issue.  One problem is that
not only does Microsoft have a copy of a bulletin on their site, but it is
often replicated, summarized, and catalogued on many different
security-related sites on the internet.  Furthermore, admins will download
patches and sometimes print out or download a local copy of the bulletin for
future reference.  When a change is made to an advisory, then none these
copies are any longer synchronized which could lead to some very big
problems.

A bulletin could be changed in a number of ways.  It could be updated with
more information, a new patch could be released dealing with a greater scope
or a new twist, or a new patch could be released that deals with a related
problem.

The problem is that MS is not very consistent in dealing with these issues.
Sometimes they release a new bulletin and a new patch
(MS00-093/MS00-055/MS00-033) and sometimes they will just go back and change
the old bulletin and patch (MS00-086).  Sometimes they issue a new bulletin
and change the old patch as well (MS00-031/MS00-044).  And sometimes a new
patch will just include the fixes of old patches (MS00-055).

Microsoft needs to implement a better change control policy that clearly
defines what situations would warrant a new bulletin and in what situations
it would be better to change the original bulletin.  Furthermore, each
bulletin should include a version number to distinguish between the
different changes made.  The same practice should also be followed for the
patches themselves, but more on that later.

Essentially, once a bulletin is released, it should not be changed.  Either
a new bulletin should be released or a new version of the old one should be
released.  Oh, and being released is another important point.  There have
been bulletins that were changed but were never re-released (we know, we
monitor every bulletin MS has released).

And one other big complaint: don't put a bunch of unrelated issues on one
bulletin.  Make one patch but release different bulletins.  All that does is
screw up everyone else's databases.  That's why there are often several CVE
or BID numbers assigned to one MS security bulletin.

Lack of Detail
--------------
Many have complained about how vague MS security bulletins are so I will not
go into much detail here.  I can see how they do not want to put exploit
information into the hands of hackers, but it sure would help to have some
more technical details for evaluating hotfixes and for building IDS
signatures.  To say that not giving detail helps protect anyone is a joke
and is nothing more than SECURITY THROUGH OBSCURITY.  There, I said it.

We need more information about these bulletins.  We need the details to see
if we should apply the patch.  We need IDS strings.  We need to know that
"Absent Directory Browser Argument" means to look for +.htr in your web
logs.  We often need to know what files are going to be updated.  We also
often need to know what registry keys will be changed.  We need to know if
hotfixes need to be installed in a particular order and how different
hotfixes interact.  We need to know how the vulnerability affects us as well
as how the patch will affect us.

Keeping up-to-date
------------------
The advisories are not always up-to-date on Microsoft's site.  They often
have broken links (MS00-009), references to KB articles that were never
written (MS00-080, MS00-083, MS00-093), or they say the article isn't
available but it really is (MS00-007, MS00-025, MS00-060, MS00-062,
MS00-065, MS00-070, MS00-077, MS00-079, MS00-089, MS00-094, MS00-095,
MS00-096).  And why wasn't a NT4 Terminal server patch ever made for
MS00-003 or MS00-005 that were released almost a year ago?  And sometimes
the patch is completely pulled and takes several months to be put back
(MS00-073).

Downloads
---------
Speaking of patches, Microsoft did make things easier with their new hotfix
naming convention, but there is still much room for improvement here.
First, as I mentioned before, the links sometimes just don't work.  This
last month many were fixed but for a long time before that many were broken.
And although it is a minor issue that would only bug people like us at xato,
why don't they assign release ID's to all downloads so they can be found at
the MS download center?

But a more important issue is that sometimes the same filename is assigned
to two different files for two different products (MS00-004, MS00-011,
MS00-021, MS00-027, MS00-029, MS00-047, MS00-052, MS00-059, MS00-075,
MS00-081).  That makes it very difficult if you need to download both files
to the same location.

And finally, it would be nice if the bulletin also contained a MD5 or CRC32
checksum so that truly paranoid could verify the validity of a file.

Product Categorization
----------------------
This is annoying because it is sometimes difficult to know which hotfixes
need to be applied to which products.  The problem is exacerbated when
Microsoft is not consistent when assigning to products.  For example, Java
VM is part if Internet Explorer 5.0 and Internet Explorer 5.0 is part of
Windows 2000, so bulletins like MS00-059 should also list Internet Explorer
5.0 and Windows 2000 as affected products.

Keywords
--------
Searching for patches and security-related articles would be very easy if
keywords were consistent.  But they aren't.  For example, the KB article for
MS00-036 (Q263307) uses NT4PostSP6aFix as a keyword while the KB article for
MS00-031 (Q251170) uses kbWinNT400PreSP7Fix.  Not only is the version format
much different, but what makes one fix Post-SP6a and another Pre-SP7?

Q-Numbers
---------
Although we refer to security bulletins by their MSxx-xxx numbers, every
hotfix is assigned a Qxxxxxx number, or Q-Number.  The problem is that
sometimes a Q-number is never assigned (MS00-012) and sometimes there are
multiple articles associated with a security bulletin (such as MS00-036) so
it isn't always clear which Q-number is assigned.  The problem is that in
Windows 2000 the hotfix registry entries
(HKLM\Software\Microsoft\Updates\Windows 2000\) are based on the Q-number,
not the security bulletin number. So managing hotfixes often requires some
sort of cross-reference between the bulletin numbers and the Q-numbers.

Bulletin Format
---------------
But the issue that brought all this up is that Microsoft recently decided
not to include the full text of the advisory in the messages sent out to
their mailing list as well as other public lists.  Our opinion is that it is
good practice to include the text in the article as well as a web site
because e-mails addresses can be spoofed and links in e-mails can
deceptively link to a malicious site.  DNS cache can also be corrupted as
well as a number of other things.  Having the advisory in the e-mail as well
as on the web site helps us to verify that the content is indeed coming from
Microsoft.

But on that same thought, we would also like to see Microsoft make available
text-only versions of the advisories on their web sites as well as in other
formats such as XML or even just a structured HTML table that could be
parsed.

The issue here is the dissemination of information to make the process of
keeping patched much easier so that it is done more regularly.  Being
consistent with the data makes it much easier for us to keep on top of
things and therefore much more able to protect ourselves.

If anyone is interested in seeing our hotfixes research, we have placed a
beta of the Win2k section online at our website at
http://www.xato.net/advisories/beta/win2k.htm.  We would certainly welcome
any feedback on what we have and how it could be improved.

We would also welcome feedback on the ideas presented here.  Our purpose is
to help not only Microsoft, but all vendors to have consistent and
well-managed security bulletins.  By doing that people will better
understand what needs to be patched so therefore they will more likely be
patched.  A good bulletin release policy, consistency, adequate details, and
solid change control brings us closer to that goal.

.sozni
xato network security, inc.
www.xato.net