Steve: Well, okay. First of all, it makes no sense at all in a metafile device context. In the context of processing a metafile, setting a printer abort is crazy because it's not a printer context. You don't print metafile contexts in this way. It's just not the way it's done in Windows. So it doesn't make sense. But it's like, okay, well, so maybe, you know, it's there anyway; they didn't think to remove it or take it out. Except that, when I was pursuing this and finally got it to work, what Windows did when it encountered this Escape function, followed by the SETABORTPROC metafile record, was it jumped immediately to the next byte of code and began to execute it. That is, it was no longer interpreting my metafile records record by record, which is the way metafiles are supposed to be processed. You don't actually execute the metafile. As we said before last week, and I think the week before, it's sort of a script. It's a script of Windows graphics calls that allow you to specify, you know, draw a rectangle from here to here, draw a line from there to there. And it's in a nice sort of device-independent fashion. So you don't run the code in the metafile. But what Windows did when it encountered this particular nonsensical sequence was to start executing the next byte of code in the metafile.

Leo: Hmm.

Steve: And it's like, okay, wait a minute.

Leo: Why?

Steve: You know, that's crazy. But what's even more crazy is what it took for me to make it do this. As I said before, each record in a metafile begins with a four-byte length, followed by a two-byte function number. So in other words, each metafile record has six bytes minimum that it can possibly be in size. Oh, and since the size is in words, the smallest possible size for a metafile record would be three words long, or six bytes. Look, the reason I had problems making this exploit happen initially is I was setting the length correctly. It turns out that the only way to get Windows to misbehave in this bizarre fashion is to set the length to one, which is an impossible value. I tried setting it to zero. It didn't trigger the exploit. I tried setting it to two, no effect. Three, no effect. Nothing, not even the correct length. Only one.

. . .

Leo: So you're saying intentionally or - Microsoft intentionally put a backdoor in Windows? Is that what you're saying?

Steve: Yes.

UPDATE: Here's an explanation, via James A., who says "It's a feature, not a bug".

Back in the days of Windows 3.0, code needed to be run in your image if
the user cancelled printing. Also on that page is the reason why earlier
versions are "not vulnerable" - there's no application associated with
.WMF except in recent windows versions (the image and fax viewer).

M'kay...

UPDATE: Chris says:

That doesnt explain it. The feature was to set a callback address to for code to run if the user cancelled printing. It wasnt supposed to actually run code IN The wmf file itself. Also, why have it activate something if the length is set invalidly ?

He also has this link, which is another whole kettle of crap.

UPDATE: Microsoft responds.

UPDATE: More on the Symantec one, via Aziz.

UPDATE: This is probably the final word, via James A.