The QFE release process breaks down frequently in packaging. A number of Win2K pre-sp2 patches were released with a bad sp2.cat file making Windows File protection more of a danger than an aid.
Numerous pre-sp3 patches were initially released with a hotfix.inf file that marked them as sp2 fixes. these were subsequently re-released and the only way you'd know there was a problem is HFNetCHK would report the patch missing. (I encountered about 20 out of 40) I have not determined if the incorrect setting would cause these fixes to run against sp2.cat per WFP. There was another glitch with the pre-sp1 fixes but I forget the details. The simple fact of the matter is there is a serious problem with Microsoft's QFE release process. The process, structure, and tools are well defined. It looks like they either let everyone package their own stuff and just firetest that it installs, or they have idiots for packagers. I have, on more than one occasion, had to rewrite INFs supplied with hotfixes because Microsoft didn't get it right. I am not talking about incidents in the far distant past, I am talking about recent packages. What's worse, absent the outcry of MS01-052 MS is quietly releasing the updated packages and never alerting the users who installed from bad packages, nor are they making it clear that multiple packages have been released for the same fixes if those updated packages don't update the files delivered. I have a big issue with a process this basic and rigorous failing with such consistency. This is a process one should be able to hand to college interns and get a consistent result. Of course a portion of this has its roots in the battles for a single software installation method: Acme setup, active setup, MSI, et al. I don't care who wins, but I would like some brass at MS to show some brass at MS, d3eclare a winner, and from there determine the consistent methodology for QFE deployment. (OK, probably methodologies - one for OS, and one for all else -- but then someone might need to draw the line between OS and all else.) While we're off the subject, Does anyone else find it annoying that it is not sufficient to search the MS security bulletins for OS and SP? Instead you must also search all components and the same SP to get a complete list of fixes. Last but not least hfnetchk -h whatever -o tab Dear MS - if the field is blank, please still return a tab so when i import the data for analysis I don't have to figure out which fields are munged by your crappy output format. Abesent that please publish the DTD used for mssecure.xml so I can just build a better tool. While we're on the subject could you disclose to the world that HFNetCHK is basically a beta, and a crippled beta at that. Until MSSecure.xml is fully populated, a lot of admins are patting themselves on the back and declaring their enterprises secure based on the results reported by your tools. I won't say you've done more harm than good - after all the major services are patched cutting off the most effective attack vectors for Worms, but absent closer attention MS Office still leaves some, as yet, unexploited exposures that HFNetCHK ignores. ----Original Message Follows---- From: "David N. Precht" <[EMAIL PROTECTED]> Reply-To: "MSWinNT Discussions" <[EMAIL PROTECTED]> To: "MSWinNT Discussions" <[EMAIL PROTECTED]> CC: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Subject: FYI : Problems with MS01-052 Date: Thu, 25 Oct 2001 13:43:20 -0400 -----Original Message----- From: Windows NTBugtraq Mailing List [mailto:[EMAIL PROTECTED]]On Behalf Of Russ I've waited for a week now to get additional information on the cause of the problems with MS01-052. Microsoft have seen fit not to provide us with any additional information beyond; "The issue is a result of a human error in the patch building process. Microsoft deeply apologizes for any problems this has caused. We assure you that a thorough investigation is being conducted into the cause of this problem and aggressive steps are being taken to prevent it from happening again." - From that statement Microsoft expects to reassure us that when we implement their push feature of Windows Update, we won't find our machines disabled, unable to reboot, or unable to function the service a Hotfix is intended to patch. We have to accept that the "aggressive steps" they refer to were not thought of as part of the Microsoft Strategic Technology Protection Program (MSTPP), implemented two weeks before this broken Hotfix was released to the public. There's no way I could trust such a process without the knowledge that when they screw up, they're going to make every effort to provide me sufficient information with which I can trust their future actions. MS01-052, as initially made available to the public, could not possibly have passed even basic testing. You installed it, rebooted, and the system stopped functioning properly. You either ended up with a BSOD, or your Terminal Services were unresponsive. 1. They have claimed that it was a packaging error. "The issue is a result of a human error in the patch building process.", yet it still took them 4+ days to get a revised version of the patch out. The timeframe suggests it was something other than a packaging error. NTBugtraq advised the public that the patch was broken, Microsoft did not see fit to inform people who had already downloaded the patch that it would break their systems. Sure, they stopped making it available, but what of the people who had already downloaded it? 2. According to; http://www.microsoft.com/technet/columns/security/sectour.asp "When all of the packages have been built, they must be digitally signed - after all, we need a way to assure our customers that they really did come from Microsoft. Then it's back to the test lab again. This time, we verify that the digital signature on each package is correct, that the package installs and uninstalls correctly, and we verify once again that the patch works as advertised once it's installed." Obviously MS01-052 didn't follow that process, any idiot would have been able to see that it killed the Terminal Services it was intended to fix. So how come the stated process, the one that has such new focus and emphasis, failed to follow its own basic steps? What went wrong? Who screwed up? Which part of the process failed, and how can we be expected to believe its being fixed? 3. MS01-052 was only the second Hotfix to be produced after the announcement of the MSTPP. It should have been produced under the glaring light of the new focus and emphasis that Microsoft has stated is being applied to security issues. The MSTPP announcement stated a new mechanism for getting Hotfixes out to customers was in the works, one that would allow fixes to be pushed out to clients automatically. Microsoft stated, in the Security Bulletin revision they published on MS01-052 v2.0, "Because the patches were only available for a few hours, only a small number of customers had downloaded them." Whether or not this is true isn't important, under the MSTPP such a distribution of a Hotfix could be in the systems of millions of users in the same amount of time. Clearly the new focus and emphasis failed to catch this problem, or acknowledge that Hotfixes are often rapidly downloaded and deployed. The MSTPP announcement was full of bluster but didn't follow through with effective process changes to ensure it could fulfill its stated goals. While the automatic update client is still pending, what can we look forward to? More of this type of ineffective and destructive patches being automatically installed on everyone's systems? 4. It took 4+ days to get a replacement patch. How, under the process of the MSTPP, will Microsoft handle this situation in the future? Will Microsoft automatically remove defective patches from systems which have automatically applied them? What if the problem affects networking components which prevents the machine from being able to reach the Microsoft site for such information (information that tells it to remove a defective patch)? Will users go to connect to their servers only to find out that an automatically applied Hotfix has rendered it inaccessible, or possibly even brought the system down? 5. Hotfixes, like all Microsoft software, contain the standard Disclaimer; "The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply." How can Microsoft reasonably make the claims they do about their new focus and emphasis on "Get Secure" and "Stay Secure" when there is no "fitness for a particular purpose" on a Hotfix, who's sole purpose in life is to rectify a software problem that Microsoft has acknowledged. It must be "fit for a particular purpose", it must fix the problem they state they are fixing. When it doesn't, disclaimers shouldn't apply. Especially since that disclaimer also says they won't be liable for any damages incurred. In an automatic update scenario, coupled with an ineffective and flawed Hotfix production process, customers should be able to rest assured Microsoft will make restitution when they break customers systems. You can put limitations on this, but the bottom line is that when a patch is pushed to the public which breaks all systems its applied to (as is the case with MS01-052 v1.0), Microsoft should be culpable. Their lack of willingness to accept that responsibility suggests we cannot trust a push mechanism from Microsoft. This extends to Software Subscription as well. 6. Clearly there is absolutely no need for an automatic push mechanism for Hotfixes before we have Federated Corporate Windows Update. Who in their right mind, based on this experience if nothing else, would allow their systems, typically critical systems which need patches sooner than other systems, to be automatically updated without prior testing of the patch? I sure wouldn't recommend it to anyone. So why give us the push client before we're able to push from our own Windows Update server? Finally, many of you submitted messages to NTBugtraq expressing your outrage at the way this patch was handled. Knowing the process Microsoft uses to produce patches, I defended them to the extent that I believed there was going to be an explanation forthcoming. NTBugtraq's not meant to be a venting forum, but maybe if I'd let more of you express your concerns Microsoft may have responded. I normally defend Microsoft, something I'm frequently criticized for. I privately sent email to Microsoft to encourage them to address this issue publicly, at least for NTBugtraq subscribers, to reassure us. They've decided not to do that, and they haven't responded privately to my request on your behalf. You might want to contact Microsoft yourself, at [EMAIL PROTECTED], to see if they can offer you an explanation that responds to some or all of the concerns above. Cheers, Russ - NTBugtraq Editor _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ------ You are subscribed as [EMAIL PROTECTED] Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe send a blank email to [EMAIL PROTECTED] _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ------ You are subscribed as [email protected] Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe send a blank email to [EMAIL PROTECTED]
