Use hfnetchk when Patching NT/2000/XP Systems or You May be Sorry. by Zube (zube@stat.colostate.edu) Created: Mar 12, 2002 Updated: Aug 31, 2003 http://www.stat.colostate.edu/~zube/docs/hfnetchk.txt [ Additions, suggestions or corrections always welcome. ] Patches are a fact of life of any extant operating system. One usually doesn't like it, but it sure beats the alternative. Sun Solaris patches have numbers associated with them. For example, the current Solaris 8 kernel patch is 108528-13. The -13 denotes the revision number of the kernel patch. Such a numbering system makes it easy to know what version of the patch is installed. HP (for hp-ux) does it differently. When a new revision of a patch is released, it is given a completely new patch number but the text file included refers to the older, superseded patches. In both cases, a change to a patch is clearly noted. Clarity is one obvious benefit. Another is convenience. If the Solaris patch list notes that 108528-13 is the latest kernel patch, I know that my download of that patch from weeks or months ago is still usable; I don't have to download a new kernel patch until -14 comes out. I can keep an up-to-date local patch set with little effort. So, how does Microsoft revise patches? Well, let's take a look at a recent Security Bulletin: MS02-009. http://www.microsoft.com/windows/ie/downloads/critical/q318089/default.asp states: "This is an updated version of Security Update, February 14, 2002." and it also states that the update was posted on February 21, 2002. So far, so what? On February 24, 2002 at 4:19pm MST, I downloaded the files pointed to on that page. They were 321120 bytes for the 98/NT version and 321632 bytes for the Windows 2000 version respectively. Before I started patching some of the machines here, I double-checked the bulletin and it still stated, as it does today (March 12), "Posted: February 21, 2002." So I think, ok, I'm set. After patching a few NT machines, I decided to run hfnetchk, the hotfix checker that MS released a while ago to determine which patches were not installed. It complained about vbscript.dll (which the above patches were supposed to fix) and referred me to MS02-009. I then went back to the download section and after downloading the patches again, found that their file sizes had changed. Both files were now 314,464 bytes. I then unpacked both the old and new NT patches and looked at the file date and the version number on each. The results were: old: 1-02-02, version 5.5.0.7302 new: 2-28-02, version 5.5.0.7426 Amazing. And it isn't the first time, either. I found myself in similar situations with the windows 2000 patches from MS01-007 and MS01-013. Lesson: use hfnetchk regularly because Microsoft will change the contents of patches without notice. ************* I thought I had seen it all, but MS02-052 takes the cake. First, the only way to get the patches is through Windows Update. The bulletin maps out a twisty path if you are "a network administrator" and want to "download it and install it on all my users systems" but the instructions do not apply to Win98/ME/NT, which uses the "old" (version 3.1) windows update. Who cares, right? Only morons use those OSs. Cool network admins use only Windows 2000 and XP. What's also cool is that the only patches available this way are for Windows 2000, XP and .NET. There is no choice to download the patches for 98/ME/NT. Just use Windows Update and shut up, ok? [Note: For the record, MS recently changed the Win98 and WinME updates to version 4. NT is still out in the cold, though. ] Oh, but we're just getting started. Run jview from a cmd prompt to determine the build version, just like the bulletin suggests. If you've been keeping up, it will be 3805. Now go get the patch, install it and reboot. Go back to a command prompt and run jview again. What does it say. Right! 3805. It turns out that to determine if the patch was installed, you must search for this key in the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\ {DBB3C81D-3C91-4a1e-BDDF-905B61C7CEDF} and under there you'll find the Version value is 3807. That's *so* much easier. Thanks Microsoft. ************* This beat goes on ... This section might be called "... But Don't Bother about the NT, Please." Today is Aug 30, 2003. NT Server is supposed to still be supported, by MS anyway, and (perhaps by extension) Shavlik, as it seems to be the company that developed hfnetchk. The latest command-line hfnetchk from Shavlik Technolgies, v. 3.86.01 works on NT/2K/XP, but it does not pick up the MDAC 2.8 patch. Advice from the folks at Shavlik? Download the huge, kitchen-sink hfnetchkLT and use the command-line scanner included in it. Ok, did all that and it, without any other libraries or anything, works great on 2K and XP. It doesn't, however, work on NT. It's looking for secur32.dll, which (I believe) replaced WinNT's security.dll. So, if you put MDAC 2.8 on an NT machine, hfnetchk will not acknowledge it. One may convincingly argue that Shavlik made a decision to stop supporting NT and that NT is mostly out to pasture. It's true; the real blame does not fall on them. The blame must be placed squarely on MS. hfnetchk 3.82, which comes with the MS Baseline Security Analyzer, doesn't check for any MDAC bits according to: http://www.microsoft.com/technet/security/tools/Tools/mbsahome.asp so the fact that Shavlik's hfnetchk 3.86.01 does has long been a reason to use Shavlik's version. But now, there is no way to easily and locally check to see if MDAC 2.8 is installed on an NT machine. Thanks again, MS. There is a small set of English words called auto-antonyms, words that mean both X and !X. For example, fix may refer to a solution ("a quick-fix") or a problem ("I'm in a fix."). You can find a fair number of these here: http://graphics.lcs.mit.edu/~seth/misc/selfantonyms.html I hearby nominate the word trustworthy, in both its normal usage ("able to be trusted") and the Microsoft usage (Trustworthy Computing, meaning "not to be trusted") as another auto-antonym.