Was the WMF flaw intentional?

["Richard M. Smith" <rms () computerbytesman com>]

http://www.grc.com/x/news.exe?cmd=article
<http://www.grc.com/x/news.exe?cmd=article&group=grc.news.feedback&item=6000
6> &group=grc.news.feedback&item=60006
 
Subject:         Re: You won't want to miss tonight's Security Now!, #22

Date:    Thu, 12 Jan 2006 18:46:56 -0800        
From:    Steve Gibson <news2006 () grc com>     

  <http://www.grc.com/image/darkbluepixel.gif> 

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

_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.