The truth about the Windows WMF exploit

Once upon a time, talking to an old friend, which happens to be a known hacker in my country, he told me that Windows had a backdoor, designed to be used only by people at Microsoft.

I never believed him.

Silly me.

As it turns out, he was right, not only once but several times, about Windows having intentional backdoors, hidden by Microsoft itself. Here's the latest Windows backdoor coming out of Redmond: the WMF exploit. This is a discovery by Steve Gibson, a real, true, genius hacker who's been around the scene for several years now (some say more than a decade).

And, as Steve says, there's simply no way this particular WMF exploit was accidental. The way it works, it has to be intentionally put there. He's right.

Quoting from the transcript of the interview with Steve:

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.

So what I found was that, when I deliberately lied about the size of this record and set the size to one and no other value, and I gave this particular byte sequence that makes no sense for a metafile, then Windows created a thread and jumped into my code, began executing my code. Okay, Leo? This was not a mistake. This is not buggy code. This was put into Windows by someone. We are never going to know who. We're never going to know - well, actually I'm going to find out when because we're going to know when this appeared because this appeared - I'm guessing this is not in older versions of Windows, which is why this function - or if it is in older versions of Windows, it's done slightly differently. I'm still on the hunt.

Steve: No. No. I mean, you know, again, this is as much a surprise to me, Leo, as it is to, you know, anyone who hears this. I did not expect to see this. I expected to find, for example, that the way this exploit worked was that the SETABORTPROC was working correctly, and that I would give it a pointer to my own code a few bytes lower, then I would do something to force the metafile to abort, and then the metafile processing would use the pointer, the legitimate SETABORTPROC pointer, and then basically run the code that was located right there in the metafile. That's what I thought I was going to encounter, something that sort of made sense, like we were originally led to believe. Or actually I think, you know, Microsoft didn't say anything at all. So we just all kind of presumed this was another one of those coding errors that Microsoft now famously makes and corrects on the second Tuesday of every month. This wasn't a programming error. And, you know, so it's like, whoa. When I give it the magic key on the size of the metafile record, then it jumps directly into my code.