[for the unabridged version, see Sam Schinke's post above]

> There is some interesting discussion of this issue in
> the thread beginning with this post:
> 
> http://www.GRC.com/groups/security:108750
> 
> Apparently, this function stems from the _very_ early windows
> days and could be used to aid in safely aborting printing,
> or something like that.

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.