LAN-Fax driver crashes, reboots or "Blue Screens" my computer - I do *not* recommend that you remove the ANI fix unless the LAN-Fax software is a critical line of business application. New LAN-Fax drivers will be released and available for download on April 10th, 2007.
CrystalXP - I recommend you uninstall CrystalXP and keep the security patch in place unless CrystalXP is a mission critical application. There is no information available about when CrystalXP will be updated.
Editorial: I've been reading through the fallout of this release on various forums with some people stridently complaining because MS released this patch when MS knew there were going to be problems. Well, dear reader, let us remember that MS also knew that the security vulnerability being patched by MS07-017 was being actively exploited, and some were calling for Microsoft's blood because Microsoft, in their opinion, did not release the patch quick enough. By the time the patch was released hundreds of Web sites had been hacked for the express purpose of using the exploit, and spam-blasts were occurring that also tried to take advantage of the vulnerability.
So, what is it that we want of Microsoft? Seriously. It is simply not possible for MS to test their patches against the millions of different software applications out there in the world. I'd never heard of CrystalXP before today, just like I'd never heard of ElsterFormular, TUGZip and CD-Tag or LAN-Fax. On the other hand, I *had* heard of Realtec, but Microsoft had the fix all ready to go.
Now, as for CrystalXP, it seems that that program replaces the system file shell32.dll with its own version. There is no way MS can anticipate how an obscure third party application is going to hack an MS system file. For CrystalXP to claim that "microsoft installed a buged updated" [sic] is disingenuous. It would be more correct to say that "CrystalXP's version of shell32.dll is not compatible with the security fix". And as for their advising users to remove the patch, isn't making sure users are protected from an actively exploited security vulnerabilities more important? It is wrong, wrong, wrong of CrystalXP to simply tell users to uninstall the patch, and to hope that Tuesday's security update will fix their problems for them. Follow Ricoh's and Realtec's lead and fix your software so that your users can stay patched.
In an ideal world the hotfix that resolves the errors with the Realtec HD Audio Control Panel and other software would have been rolled out at the same time as MS07-017, and not offered as a separate download, but that is not what happened. I understand the inner workings of MS update releases - the different branches and testing standards that apply to different types of updates - and the dilemmas that MS face when deciding how and when to release patches. Should MS have deferred releasing the security patch to wait for the hotfix that had hit the standard required of a limited release hotfix with all of its additional provisos and disclaimers and warnings, but was not yet ready for unfettered distribution? Considering the active exploiting of the vulnerability, I have to say that they did the right thing by not deferring the security update.
Ok, so that leaves us with the "MS should have warned us that there were problems with Realtec". Putting aside the fact that this information was in the documentation (yes, I know, nobody reads that stuff), the argument can be made that Microsoft probably should have popped up an alert at the time the security update was being installed to warn anybody with the affected Realtec software installed that they needed a hotfix. But what if tailoring the detection logic would have delayed release of the patch? MS were already being criticised for waiting as long as they had.
We find another dilemma once we go down the "warn people if there is a conflict" path. There are often issues with a security update that are discussed in the documentation so how do we decide what requires a special alert and what doesn't? Do we only alert if there is a hotfix available? If an estimated X number of PCs are affected? And what happens if we are installing several security updates, which would require several alerts about conflicts that could confuse and frighten the user? What if those alerts frighten the user so much they simply don't install the security updates at all? That would be a bad thing. And what happens when somebody complains because they were warned about a problem with program x, but not warned about a problem with program y?
Historically, presenting users with a series of warnings does not work well. They don't read them properly, or they don't read them at all and just click through. Here are two real world cases that illustrate this point. I generally lock a server when I am not working on it using the Windows L key combination. One day I was going to be away for a couple of days so I handed over certain responsibilties to a different staff member. That staff member needed to log on to the server. The staffer hits ctrl alt del and is presented with the traditional "somebody else is logged in, are you sure you want to do this, they may lose their work" dialogue box. But, this senior staff member did not *read* the dialogue box and instead assumed that the wrong password had been entered. The staffer acknowleges the dialogue and tries again.... and again... and again... and again... and again... and again... before finally coming to me and saying there is something wrong with the password. Not once did the staffer pause long enough to *read* what the dialogue box was saying. So, because this staffer has demonstrated on several occasions a disinclination to read dialogue boxes I have had to adjust my behaviour to work around that person's deficiency. If I am going to be away, I log out of the server instead of locking it (a pity, because Windows L is so much more convenient).
Then there was another incident. A user was presented with a dialogue box warning that a programme would not work unless the system's short date format was set to dd/MM/yyyy. The dialogue box is quite clear and says "this is the problem, and this is the fix". Yet once again, the user did not *read* the dialogue box, nor did the person called in to assist the user. This resulted in inappropriate steps being taken to avoid the error.
So, what's the end result of all of these ponderings?
- delaying a security patch that is important enough to justify an out of band release until a hotfix is ready for general distribution would have been a bad thing because the ANI vulnerability was being actively exploited
- a dialogue box directing only affected users to the hotfix would likely have delayed the fix for everybody, and run the risk of confusing affected users (assuming they actually read the dialogue box anyway - the person described above certainly would not have done so)
- warning *everybody* that Realtec software is a problem would have caused more confusion - many users know they have that little red speaker icon in their system tray, but they can't put a name to it and we run the risk of people not installing the critical fix at all, just in case they have Realtec.
- warning *everybody* that a hotfix is available if you see <insert error> would be confusing - the error text was long, and obscure, and few would bother to write it down just in case they see it - if anything users would download and install the hotfix "just in case" which is a bad thing in itself - hotfixes should only be applied to systems affected by the specific symptoms it fixes.
- by warning about Realtec, are we setting a standard of disclosure that will cause problems going forward ("you warned me about program x but not about program y", "all those dialogue boxes are too confusing")
I am so glad I don't have to make such decisions.