WMF Flaw not a Backdoor

koro666 writes "In a blog post, Mark Russinovich from SysInternals responded to the allegations made by Steve Gibson labeling the flaw as an intentional backdoor. It seems that the hype was about Steve's discovery that the code would only be executed if the size of the metafile record was deliberately tampered with, which is not the case. The technical details are explained in his post."

Comments

Re:it doesn't matter

[vdboor]

Conspiracy theories don't need reasons backing them up

You've got a good point here and it describes the other side of of Steve Gibson. After reading that site, you'll understand his stories are mostly made of popular speak or disinformation, rather then scientifical information.

So while you may admire him for his charisma, you shouldn't for his expertise. Would you e-mail him about an error, he'll silently correct it as if he'd always known it. You won't find him at an official security conference, but in the eyes of his fanbase he remains a god. I can image people are felling for his stories through, his stories make you get excited easily.

Re:Back door or poor design? You can't really tell

[spectecjr]

Either way, it is still hard to tell why it was designed that way in the first place, maybe one of these links can tell us?

It's quite simple:

WMF is used under the hood in lots of places in GDI. Any time GDI passes a bunch o' commands from one place to another, you'll find WMF. And as a result, WMF encapsulates almost everything you can do with GDI.

SetAbortProc is used to allow an app to display a custom "Printing Page xxx of xxx... [Cancel]" dialog to be displayed on Windows 2.0, 3.0 and 3.1, all of which are cooperatively multitasking and so need to drain their message queues on a regular basis - which they do every time that AbortProc is called.

There are even examples of this exact behavior on MSDN. It's still semi-useful under later versions of windows to be able to do this, and it's good for backwards compatibility, so it stuck around.