- Samuel's Blog - https://samuelgordonstewart.com -

Steve Gibson declares WMF Exploit a deliberate backdoor

Posted By Samuel On In IT News | Comments Disabled

The WMF Exploit has been discussed on this site before, both here [1] and here [2], 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 [3] episode 22 [4] (which can be heard here [5]). 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 http://www.grc.com/sn/SN-022.htm [6] or listen to Security Now! Episode 21 at http://media.grc.com/sn/SN-022.mp3 [5].

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.

Samuel

Comments Disabled (Open | Close)

Comments Disabled To "Steve Gibson declares WMF Exploit a deliberate backdoor"

#1 Comment By heatseeker On January 14, 2006 @ 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 Comment By Samuel On January 14, 2006 @ 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 Comment By Some Guy On January 14, 2006 @ 5:59 pm

That’s a load of rubbish. The exploit details were mentioned on [7]. 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 [8].

#4 Comment By Samuel On January 14, 2006 @ 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 Comment By heatseeker On January 14, 2006 @ 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 Comment By Samuel On January 14, 2006 @ 11:28 pm

Steve summarised this at [9] 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
print.

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
application.

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,
etc.

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
Context.

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.

No…

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.

—
________________________________________________________________
Steve.

#7 Comment By Samuel On January 14, 2006 @ 11:33 pm

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

#8 Comment By Some Guy On January 15, 2006 @ 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 Comment By Samuel On January 15, 2006 @ 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.