Another professional developer and industry associate with a great deal of reverse-engineering and low-level systems programming experience wrote to me, which I quote with his permission (emphasis is his):

"I've learned more and talked this over with peers. I think your argument is MUCH more convincing than Microsoft's explanation; though if this back door is intentional, the Microsoft guys answering the accusations likely don't know anything about it ;). The idea of it being intentional has met considerable resistance by people when they first hear of it, and even I was originally resistant. But when people learn all the facts they grow surprisingly less resistant ;). One guy said, "its not like it's a jmp eax".. which is ironic, since that's EXACTLY what it is."

Toward the end of the day following Security Now! episode #22, Microsoft's Security Research Center (MSRC) posted a "blog page" which was clearly a reply intended to address the points I had raised during the podcast. You can see the entire blog as it was posted with this MSRC link.

Since it is quite lengthy, I am going to excerpt pieces from it and respond in-line to just some of what it states. Please read the entire original blog posting in order to understand Microsoft's entire official position:

Excerpts and comments from Microsoft's MSRC January 13th, 2006 blog posting:

Stephen Toulouse, for Microsoft: "The vulnerability was introduced when all that GDI functionality was allowed to be called from metafiles." This is very misleading. There is nothing inherently vulnerable about metafiles. This is demonstrated by the fact that all proper metafile processing works just fine today, after Microsoft patched Windows to remove the previously hidden MICE behavior. The TRUTH is that "the vulnerability" was introduced when Microsoft silently changed a function in metafile processing to allow execution of image code. After it became public knowledge they changed it back, and all is well. "The potential danger of this type of metafile record was recognized and some applications (Internet Explorer, notably) will not process any metafile record of type META_ESCAPE, the overall type of the SetAbortProc record. That restriction is the reason it's not possible to exploit this vulnerability by simply referencing an image directly in HTML. IE just won't process it." Okay . . . So now Microsoft says that they already knew about the "potential danger of this type of metafile record", but — for some unexplained reason — they chose not to fix it, as they have now done. Instead, they told Internet Explorer not to process those "potentially dangerous" metafile records. The TRUTH is that none of these "potentially dangerous" Escape functions are needed inside metafile images at all, as proven by the fact that Internet Explorer has never processed them. And neither are they truly dangerous when they are written to function as specified and documented (and as they originally did operate). But, again, rather than remove these functions, which Microsoft says they believed were dangerous, they not only remained inside Windows, but were intentionally altered, as we saw above, to allow metafiles to run executable code. (For some reason, Microsoft MADE them dangerous.) "Now, there's been some speculation that you can only trigger this by using an incorrect size in your metafile record and that this trigger was somehow intentional. That speculation is wrong on both counts. The vulnerability can be triggered with correct or incorrect size values. If you are seeing that you can only trigger it with an incorrect value, it's probably because your SetAbortProc record is the last record in the metafile. The way this functionality works is by registering the callback to be called after the next metafile record is played. If the SetAbortProc record is the last record in the metafile, it will be more difficult to trigger the vulnerability." Yep, I got that wrong. Stephen Toulouse and Microsoft are completely correct on this count. My original vulnerability test metafile contain only a single SETABORTPROC record. Mark Russinovich also independently confirmed that this was the reason for what I encountered in my preliminary experiments. (See Mark's eMail to me.) GRC's "MouseTrap" and "MouseTrapCmd" utilities use a six-record metafile where setting proper lengths for the metafile records works as expected and successfully triggers the metafile image code execution behavior. "With WMF we want to be very clear: the Windows 9x platform is not vulnerable to any "Critical" attack vector. The reason Windows 9x is not vulnerable to a "Critical" attack vector is because an additional step exists in the Win9x platform: When not printing to a printer, applications will simply never process the SetAbortProc record. Although the vulnerable code does exist in the Win9x platform, all "Critical" attack vectors are blocked by this additional step." This conclusion to the MSRC blog posting is the most confusing and disingenuous set of statements of all. Microsoft MUST know what I and others have determined after careful examination of Windows 9x: All systems before Windows NT are absolutely not vulnerable to abuse of the SETABORTPROC function because in all those earlier systems it works the way the documentation states, and is incapable of running code in a metafile image. Does Microsoft hope to deliberately frighten the millions of people who are still happily using Windows 9x into upgrading to newer operating systems? Microsoft also states that Windows 9x platforms are "not vulnerable to any 'Critical' attack vector" because they take additional protective steps. This would lead any reasonable reader to ask why the later, now-vulnerable versions of Windows have had these beneficial "additional protective steps" removed?