Dynamic Analysis and Debugging of Binary Code for Security Applications - Runtime Verification - page 419

Fig. 7. Case Study: The WMF Key Data Structures
WMF is very complex. In short, the overall WMF file structure has one meta header,
followed by zero or more meta records. The key structure of the WMF file format is
shown in Fig. 7.
Each meta data record is an encoded Windows GDI (Graphics Device Interface)
function call. It is a means of storing and playing back the command sequence that nor-
mally would be sent to GDI to display graphics. Among the meta records, one type is
called the escape record. Although this type of record is deprecated, the code that han-
dles the record has not been removed in a timely fashion. If an escape record contains
certain values for the Function (0626) and Parameters (09) fields defined in the WM-
FRECORD structure, the SETABORTPROC escape will inform GDI to call a function
provided in the file. This vulnerability allows remote attackers to execute arbitrary code
via a WMF format image with a crafted SETABORTPROC GDI Escape function call,
related to the Windows Picture and Fax Viewer (SHIMGVW.DLL). It is relatively easy
to craft a WMF image file and cause the viewer application to crash.
The lower part of Fig. 7 shows an WMF file with 68 bytes. From the time the viewer
program finishes reading the file to the point where an exception happens, 76,618 in-
structions would be executed. Given that most people do not know WMF format well,
we can assume that it is difficult to manually identify which bytes of the WMF file
are responsible for the crash, how many instructions are directly involved in rendering
the file, from which functions, and under what condition. Without such information, it
would be difficult to understand the root cause of this vulnerability. From the exploit
development point of view, it would not be obvious which input bytes are critical to a
working exploit, and what are the constraints a working exploit must satisfy.