Bold Predictions For IT In 2006 New Episodes of As Time Goes By

Steve Gibson declares WMF Exploit a deliberate backdoor

January 14th, 2006 at 02:50am

The WMF Exploit has been discussed on this site before, both here and here, but the information which has come to light since then is astounding.

As you may know, security expert Steve Gibson said if Microsoft didn’t release a patch for Windows 9x, he would, so he set about doing that. Steve spent plenty of time researching exactly how the WMF exploit works, and found something very scary indeed. According to Steve, the WMF exploit was not and error, it was a deliberate backdoor from Microsoft, enabling those in the know to execute code.

A WMF file is really a graphic script which tells Windows to draw a line here which is this long, and a rectangle over here which is “x” high and “y” wide with a purple fill colour, and so on. To aid this, the file contains headers, including one for length of record (each line, rectangle or otherwise is a record”). Setting this value to 1, which is a perfectly invalid number in this context, makes Windows behave in an odd manner…it treats everything after that in the file as executable code and runs it.

Steve has announced this in the Security Now! podcast episode 22 (which can be heard here). To quote some of the discussion between Steve Gibson and Leo Laporte:

Steve:But the only conclusion I can draw is that there has been code from at least Windows 2000 on, and in all current versions, and even, you know, future versions, until it was discovered, which was deliberately put in there by some group, we don’t know at what level or how large in Microsoft, that gave them the ability that they who knew how to get their Windows systems to silently and secretly run code contained in an image, those people would be able to do that on remotely located Windows machines…

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

Steve: Yes.

Leo: Well, that’s a pretty strong accusation. Could this not have been a…

Steve: Well, it’s the only conclusion…

Leo: It couldn’t have been a mistake?

Steve: I don’t see how it could have been a mistake. Again, I’m going to continue to look at it. But from what I’ve seen now, this had to be deliberate.

Leo: But let me ask you one more – you’re convinced there’s no way this could have happened by accident. It can’t be a programming error or bad design.

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.

Steve: Now, you know, if Microsoft had said last week, whoops, this was an undocumented backdoor or means for us to run code in a metafile, we never documented it, our security sweeps didn’t find it, blah blah blah – but nothing was said. They allowed the industry to believe that this was just like all their other code mistakes, but this wasn’t like all their other code mistakes.

Leo: Well, it’s a very serious indictment, if not of Microsoft, maybe of a renegade programmer inside Microsoft. If you were doing a code review, would this kind of thing stand out? Would it be fairly obvious that something was going on?

Steve: Yeah. I mean, I’ve seen Microsoft source code. In the old days they used to publish the source for what’s called the DDK, the Device Driver Kit. And, you know, they’re very cautious about, you know, on a module-by-module basis, there’s the person’s name or initials and when they made changes and what they made to the code that follows. So, I mean, again, Leo, we’re never going to know for sure. I mean, I’ve been in this position with Microsoft in the past, or similar positions. And, you know, it’s very difficult to get a straight answer from them. So I don’t know what their source says. But it seems to me that somebody had to have seen relatively recently, certainly since Windows 2000, had to have looked at the code, seen that this was something that was there, and just kind of nodded to himself and said, yup, that’s what we want to have in our metafile processing code.

Leo: Wow. Well, I’m sure we’ll hear more about this. I think you probably are going to stir up a hornet’s nest here. And if Microsoft would like to come on the show and respond, you absolutely are welcome to do so. I’d like to hear an explanation.

In the interests of space, I have not copied every detail, and there is a lot discussed. You can rea the full transcript at or listen to Security Now! Episode 21 at

Steve is rarely wrong about these things, so this is a major concern. There is some use for this “feature” in that Microsoft could have embedded a super important patch on all of their websites and had it patch an awful lot of computers, but it was also an accident waiting to happen, which did happen a few weeks ago.

As Steve said, this is something which would stand out in a code security audit, and Microsoft have done a few audits on their code, so this almost has to have been something Microsoft purposefully placed there.

More details as they come to hand.


Entry Filed under: IT News

Print This Post Print This Post


  • 1. heatseeker  |  January 14th, 2006 at 11:39 am

    I didn’t know that Gibson bloke was a computer expert as well as being on radio and a megastar in Hollywood … soooo talented.

    Any chance of you and Natty getting a photo of him? Braveheart theme would be great, or Mad Max 2. Myabe you can be crazy Lethal Weapon sidekicks – it would look great next to the Santa photo!

  • 2. Samuel  |  January 14th, 2006 at 12:00 pm

    I think you’re getting confused about names again heatseeker. Steve Gibson is an IT Expert. George Gibson is on radio. Mel Gibson is the movie star.

    As much as I would love to claim that podcasts are radio, they aren’t, so Steve isn’t on radio, but he is on a couple podcasts.

    That being said, it would be something extraordinary to get a photo with Steve, George, Mel and myself….

  • 3. Some Guy  |  January 14th, 2006 at 5:59 pm

    That’s a load of rubbish. The exploit details were mentioned on F-Secure. The executable code forms the fallback mechanism in case reading the file fails.

    Since I suck at explaining, I’ll point you, and others, to this post.

  • 4. Samuel  |  January 14th, 2006 at 8:41 pm

    No, that’s what everyone thought before anybody took a proper look at how it works. Steve spent a lot of time looking at how precisely this works so that he can write a patch for Windows 9x.

    It does make use of that function, but in a very odd way.

  • 5. heatseeker  |  January 14th, 2006 at 11:26 pm

    So he’s not the same guy who writes sport for The Sunday Telegraph? I’d be really impressed if her did that too!

  • 6. Samuel  |  January 14th, 2006 at 11:28 pm

    Steve summarised this at which I have mirrored below. Steve describes the whole thing much better than I can, it is mildly technical, but read through it, it should make sense by the end.

    All “rendering” of graphical content, whether on screen, in
    memory, or to a printer, is done inside if a “device context” or
    “DC” in Windows jargon. The Device Context (DC) literally
    provides the “context” for the various drawing functions. You
    create pens and “select them into” the “context”. Or you set
    the context’s current foreground color or background color. The
    “context” provides a sort of “modal stickiness” for the drawing
    functions so that you don’t need to (redundantly) specify the
    line width, foreground color, background color, drawing mode,
    etc. etc. with each call to drawing functions.

    So the Device Context is the “holder” for many current aspects
    of the drawing state.

    The screen has contexts, metafiles have contexts, and printers
    have contexts. When a printing context is handed over to
    Windows for printing the app is able to wash its hands of the
    “print job” and go on with other things. But what if the user
    were to cancel the print job after Windows had “accepted”
    responsibility for printing it from the application. Since the
    application was officially “done” with the printing, it would
    not waiting around for the completion results … it would be
    onto other things — like perhaps getting the next page setup to

    So one of the other things that can be set into a printer’s
    Device Context is the address of an application-provided
    “callback” — a subroutine provided by the application that is
    expressly designed to asynchronously accept the news and
    notification of a printing job being aborted for whatever
    reason. Otherwise, there’s no way for Windows to notify the

    That is what the “SetAbortProc” system was designed to do.

    Originally, this was performed by using a GDI Escape function
    with the “subfunction” of “SetAbortProc”, then later
    “SetAbortProc” was promoted to its own full-blown standard
    Windows GDI API call.

    Either way, the call to “SetAbortProc” hands Windows a
    “pointer” to a subroutine provided by the application and
    Windows simply stores that four-byte pointer into the printer’s
    device context … just like it stores the current pen color,

    Now …

    Windows MetaFiles are a completely different sort of animal.
    When you create a MetaFile you are actually creating a MetaFile
    Device Context that starts out blank. Then, as the GDI
    functions in the MetaFile are executed, those GDI drawing
    functions are “drawn” or applied onto the Metafile’s Device

    But MetaFiles are not “printed”, to do that you need a “printer
    Device Context”, which is different from screen contexts and
    metafile contexts. So it makes no sense to set an abort proc in
    a metafile. But even so, there would presumably be no reason
    for not allowing an abort proc to be set.

    However, this is NOT at all what the WMF processing code does.

    What you would expect is that when Windows is reading a WMF
    file, and the MetaFile ESCAPE code is encountered, followed by
    the SetAbortProc subcode, there would be an argument specifying
    a Device Context and a second argument pointing to a user-
    provided function that is to be executed in the event of a
    printing abort.

    But that’s not what happens: When these affected versions of
    Windows are reading a WMF file, and the ESCAPE code is
    encountered, followed by the SetAbortProc subcode, Windows
    simply jumps to the next byte in the file and begin executing
    the code found there. Nothing is stored in the Device Context,
    no “abort” is awaited.

    And, what’s more … remember my posting yesterday where I said
    that I had some initial trouble getting my own tester to trigger
    the exploit? The reason for that was the clincher for me, up to
    this point: The only way to get this special behavior is to
    deliberately mis-set the LENGTH of that ESCAPE/SetAbortProc
    metafile record to ONE.

    The first four bytes of any metafile record is the length of the
    record in two-byte words. My tester was initially setting it to
    the correct length for my “exploit” record … and nothing was
    happening. It was only when I deliberately mis-set the record’s
    length to exactly ONE — zero didn’t work, two didn’t work,
    nothing else worked … just ‘1’.

    But since EVERY METAFILE RECORD starts out with a mandatory
    four-byte record length, followed by a two-byte function code,
    the smallest possible record is six-bytes, or a size of THREE
    words. Therefore the use of a word-length of ONE is impossible.

    It was put in there as a safety interlock to prevent the mis-
    firing of this backdoor in the event that some whacky metafile
    would actually HAVE a needless (because it’s not a printer
    device context) Escape/SetAbortProc metafile record.


    The only conclusion that can reasonably be drawn is that this
    was a deliberate backdoor put into all of Microsoft’s recent
    editions of Windows. WHY it was put in and WHO knew about it,
    and WHAT they were expected to use it for … we’ll never know.


  • 7. Samuel  |  January 14th, 2006 at 11:33 pm

    No, Steve doesn’t write for the Sunday Telegraph, or any newspaper.

  • 8. Some Guy  |  January 15th, 2006 at 3:34 am

    My apologies for not reading your post properly, it’s more interesting than I thought, though I don’t agree with Steve’s conclusion. I’m curious though, if this is the case, why it was not mentioned anywhere else.

  • 9. Samuel  |  January 15th, 2006 at 3:31 pm

    Probably because Steve is the only person trying to write a patch for older versions of Windows and therefore the only one who has needed to spend so much time checking every minute detail of the exploit.

    Apparently some other security agencies are now looking at Steve’s research…so we may soon know for sure whether or not he is correct.


January 2006

Most Recent Posts


Blix Theme by Sebastian Schmieg and modified for Samuel's Blog by Samuel Gordon-Stewart.
Printing CSS with the help of Martin Pot's guide to Web Page Printability With CSS.
Icons by Kevin Potts.
Powered by WordPress.
Log in