Firstly, let me state up front that Microsoft did an extensive
investigation into the assertion there were two versions of the MS02-018
patch, one via the Security Bulletin link, and the other via Windows
Update. They determined that both patches were the same, and that there
never were two different patches. See the 2/22/2002 NTBugtraq message
from Gurdon Merchant with "SteppingMode" in the subject for details on
how you can verify this for yourself in the future.

This message is intended to provide some evidence and background
information regarding the useless nature of Windows Update (in its
current state). This information becomes even more important upon the
release of Windows Update, Corporate Edition, a solution which I
believed was going to finally solve patch management issues with MS
platforms once and for all. As you'll see below, I no longer believe
this based on an investigation I conducted over the past few days.

Susan Bradley, CPA aka \"Ebitz SBS-MVP\"" <sbradcpapacbell.net>, in a
message to the list which I rejected, said;

"FWIW - It's not recommended to use the Windows Update on a server. It
does have discrepancies. Consider it version 1.0 and use a controlled
push/pull rather than WU."

She went on to recommend one of the various 3rd party tools available to
manage patches (and in the context of this message, patches refer to
hotfixes, service packs, security roll-ups, cumulative fixes, etc...)

Windows Update was intended to be a consumer update site allowing easy
detection and installation of patches made available by Microsoft.

In the old days, Microsoft used to make patches available via FTP. I
wrote a nice little utility which scanned Microsoft's FTP site
regularly, sucked down information about new patches in all their
various flavors (for different languages, OS', processors, etc...) and
provided a single page on my website where you could make your choices
and see what patches were available. The page provided links to the
patches, and you could easily download all of them.

Of course this didn't address the need for you to be able to determine
what was already installed on your system, or what a given system
needed.

Mark Edmead wrote a utility which would check your registry and see what
had been installed based on the presence of registry values;

HKLM\Software\Microsoft\Updates or
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Hotfix

Both (hopefully) store keys for all of the patches you've applied. A
basic approach, but far more than we had *for free* previously. The
downside of these utilities were that they couldn't tell whether or not
patches had been installed in the correct order, a crucial component of
installing patches in the pre-Windows File Protection days.

Windows Update, it turns out, uses the same method. WU simply checks the
registry keys for the presence of the patch key, and checks a value
stored there called "Installed" to see if its 1. If it is, WU won't show
you the patch, it assumes its been installed.

http://windowsupdate.microsoft.com

HFNetchk, another free tool from Microsoft but with limited capabilities
(limited product knowledge that will hopefully be expanded in the
future, limited reporting that is greatly enhanced in the fee-based
version), does a file check. HFNetchk uses a reliable mechanism,
downloads an XML file containing all of the pertinent details of all
patch files (and their contents) and then scans the files actually on
disk to make a comparison. Any discrepancy, for whatever reason, is
reported (or can be reported if verbose mode is enabled).

http://www.microsoft.com/technet/security/tools/tools/hfnetchk.asp

Microsoft Baseline Security Analyzer, another new free tool from
Microsoft, not only looks for missing patches but also checks various
configuration settings to see if you haven't addressed known insecure
configuration settings. Since it uses HFNetchk for patch checking, it
can be considered the same as HFNetchk with respect to patches.

http://www.microsoft.com/technet/security/tools/Tools/MBSAhome.asp

There can be many different problems with the method used by WU.
Problems that were, in part, only brought to light by using HFNetchk.
Here are a few specific examples;

1. MS02-018

In that patch, the file FSCFG.DLL, the FTP Service Configuration dll,
has the version 5.0.2195.3649 and a build date of 4/3/2002. However, the
same file, delivered as part of MS02-012, has the same version but a
build date of 2/5/2002.

Now one would think that if you apply a patch which contains a file with
the same version, but a newer date, then the newer dated file would
replace the older dated file (just in case the newer dated file simply
hadn't had its build number increased during the build).

That is, in fact, what happens when you run the MS02-018 patch
downloaded from the Security Bulletin link. After such an install,
FSCFG.DLL is the 4/3/2002 version.

However, when you run the WU installation of that same patch, it doesn't
overwrite the old FSCFG.DLL so your system is left with the 2/5/2002
version.

Running HFNetchk on a system after the WU installation will report that
the version is correct but the checksum is incorrect.

Whether or not there is actually any difference between the two versions
of this file is something Microsoft will have to tell us. They have the
same attributes other than date, but this is not conclusive.

Despite this obvious problem during installation, however, WU happily
reports that the patch has been successfully installed and merrily goes
on its way, whereas HFNetchk tells us there's a problem here.

2. MS02-008

For whatever reason, the version of the patch for XML v3.0 parsers
includes the patch for XML v2.6 parsers. So if you apply the v3.0 patch
you'll also patch your v2.6 parsers. Unfortunately, WU doesn't know how
to deal with this situation. Since the v3.0 patch installs its own key,
and doesn't also install the registry key for the v2.6 patch, WU reports
that you haven't patched v2.6 parsers if you have them on your system
(remember, it has no idea what version the files actually are).

HFNetchk actually scans the files themselves and, therefore, knows that
the v2.6 parsers have been updated and doesn't report them as being
unpatched.

3. MS02-016

Patches that are specifically for Domain Controllers are not supposed to
be made available by WU (don't ask why, let's assume that a DC shouldn't
be using such a flakey mechanism for patch management).

Despite this, WU put MS02-016 into a new section, called "Advanced
Security Updates", and made it available anyway.

I applied the patch to a DC from WU. It said it successfully installed.
However, WU has no record of ever giving me the patch, and the system is
definitely not patched (as verified by HFNetchk). I checked the registry
and could find no traces of a patch key for MS02-016 (Q318593).

Now when I go to WU from that same machine the patch is no longer
available to me. I checked with another DC, unpatched, and WU still
offers it to that machine. So why is WU convinced I've applied the patch
on the machine I did apply the patch on, the registry key isn't there
and the files aren't the correct version??

Summary
-------

A) WU cannot be trusted to display "the most up-to-date and accurate
versions of anything you choose to download from the site", a quote from
the site's "About Windows Update" page. This fact is demonstrated by
both the MS02-016 and MS02-018 problems cited above. Further, you will
"waste time downloading components you have already installed", as the
MS02-008 case demonstrates.

B) WU's method of determining successful patch installation can't be
trusted either. It may report it fails to install (as it does when you
try to re-apply v2.6 of MS02-008 after applying v3.0 via WU), then again
it may say nothing (as it did in the case of MS02-016). This is critical
when it comes to Windows Update, Corporate Edition if you plan on using
that to do your patch management.

C) The premise upon which WU works is just too simplistic. Although
write access to the registry keys where the information is stored is
restricted to Administrators and SYSTEM, there's no verification that
what it thinks has been done has actually been done. It relies upon
Windows File Protection to ensure that files haven't been altered, but
it can't (and doesn't) reconcile itself. Add keys for as yet unreleased
patches and it will think they're installed, get a corrupt or altered
hive and it will think they're not installed.

So in the end, I have to agree with Susan Bradley's basic premise, don't
use Windows Update. I vehemently disagree with her that we should treat
it as v1.0, its been around long enough and MS have had ample
opportunities to fix it, it should be robust, accurate, and incredibly
reliable given how important it is. I also wouldn't agree that it can be
used on systems other than servers, its as unreliable on workstations as
it is on anything else.

See my next email for my proposals as to what to do with this situation.

Cheers,
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]