Microsoft is taking the WMF issue seriously!

January 5th, 2006

This from Rod Trent's blog:

With respect to that I would like once again to emphasize that when this security advisory was originally issued, Microsoft received reports that this vulnerability was being actively exploited and the problem was not disclosed via responsible disclosure to us, the software vendor. Once we were made aware of the issue (December 28, 2005) we immediately began developing a security update for the [tag]WMF[/tag] vulnerability on an expedited track. Normally the entire process of creating a security update from start to finish, creation, to testing, to release, takes four to six weeks. By taking as many as 200 of our people and having them focus 100% on this issue only we have cut that time down to two weeks and expect to update to be ready on January 10th for release as part of our normal release schedule (again, this is dependant on it clearing all of our quality testing but the potential is high that it will be done on time).

In our effort to put this security fix on a fast track, a pre-release version of the update was briefly and inadvertently posted on a security community site. There has been some discussion and pointers on subsequent sites to the pre-release security update. Microsoft recommends that customers disregard the postings. We will only release the update once we are as sure as we can be that the fixing of the issue of our code will not somehow impact systems negatively in some other way. Again, that target date is Tuesday January 10th provided all of the Q&A testing passes as we expect.

Rolling out a patch that's guaranteed to work and not cause huge problems for all the various versions of Windows out there is a huge job that demands a big workforce.  Some will say why has it taken Microsoft all this time to patch the code when there have been several unofficial patches in that time that work and haven't caused problems.  The answer is that [tag]Microsoft[/tag] is unlikely (I would assume anyway) to have taken steps to simply remove (or bypass) the functions that are to blame in the affected DLL file (GDI32.DLL), instead they will (I think) have concentrated on plugging up the exploit in a different way.  I've no precise details as yet and will bring them to you as soon as I have them.

This entry was posted on Thursday, January 5th, 2006 at 12:56 and is filed under Stay Secure. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

Comments are closed.