funsec mailing list archives
Was the WMF flaw intentional?
From: "Richard M. Smith" <rms () computerbytesman com>
Date: Fri, 13 Jan 2006 13:04:46 -0500
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.
Current thread:
- Was the WMF flaw intentional? Richard M. Smith (Jan 13)
- <Possible follow-ups>
- RE: Was the WMF flaw intentional? Josh Daymont (Jan 13)