Windows Metafile vulnerability

The Windows Metafile vulnerability—also called the Metafile Image Code Execution and abbreviated MICE—is a security vulnerability in the way some versions of the Microsoft Windowsoperating system handled images in the Windows Metafile format. It permits arbitrary code to be executed on affected computers without the permission of their users. It was discovered on December 27, 2005, and the first reports of affected computers were announced within 24 hours. Microsoft released a high-priority update to eliminate this vulnerability via Windows Update on January 5, 2006.[1] Attacks using this vulnerability are known as WMF exploits.

All versions of the Microsoft Windows operating system support the Windows Metafile graphics standard. All versions from Windows 3.0 to Windows Server 2003 R2 contain this security flaw.[2] However, Windows NT 4.0 and Windows XP, unless patched, are more vulnerable than earlier versions because their default installation enables Windows Metafile code execution, the source of the vulnerability.[3] Later versions of Windows do not have this vulnerability.[2]

According to computer security expert Steve Gibson, Windows NT 4 is vulnerable to known exploits if image preview is enabled.[3] Windows operating systems that do not have image preview enabled or that have hardware-based Data Execution Prevention (DEP) active for all applications should not be susceptible to this exploit.[4]

Operating systems other than Windows (e.g., macOS, Unix, Linux, etc.) are not directly affected. However, a non-Windows system could become vulnerable if it runs software to view Windows WMF files. This could include software that incorporates or clones Windows' native Graphics Device Interface (GDI) Dynamic-link library (DLL)[2] or that run Windows or Windows programs through an emulator or compatibility layer. A Unix-like system that uses Wine to emulate Windows, for example, could be exploited.[5] Gibson wrote the program MouseTrap, which his company distributes as freeware, to detect Windows Metafile vulnerability in systems running Windows and Windows emulators.[3]

According to assessments by F-Secure,[3] the vulnerability is an inherent defect in the design of WMF files, because the underlying architecture of such files is from a previous era, and includes features which allow actual code to be executed whenever a WMF file opens. The original purpose of this was mainly to handle the cancellation of print jobs during spooling.

According to Secunia, "The vulnerability is caused due to an error in the handling of Windows Metafile files ('.wmf') containing specially crafted SETABORTPROC 'Escape' records. Such records allow arbitrary user-defined function to be executed when the rendering of a WMF file fails." According to the Windows 3.1 SDK documentation, the SETABORTPROC escape was obsoleted and replaced by the function of the same name in Windows 3.1, long before the WMF vulnerability was discovered. However the obsoleted escape code was retained for compatibility with 16 bit programs written for (or at least backwards compatible with) Windows 3.0. This change happened at approximately the same time as Microsoft was creating the 32 bit reimplementation of GDI for Windows NT, and it is likely that the vulnerability occurred during this effort.

The 'Escape' mechanism in question allows applications (not metafiles) to access output device features not yet abstracted by GDI, such as hardware accelerated Bézier curves, encapsulated postscript support, etc. This is done by passing an opcode, a size and a pointer to some data to the call, which will usually just pass it on to the driver. Because most Escape calls produce actual graphics, the general escape mechanism is allowed in metafiles with little thought originally given to the possibility of using it for things like SETABORTPROC, modern non-vulnerable metafile interpreters now checks the opcode against a blacklist or whitelist, while keeping the full set of opcodes available to regular code that calls the GDI escape functions directly (because such code is already running in the same way as the code it could make GDI call, there is no security risk in that case).

It is worth noting that 16 bit Windows (except the rarely used Real mode of Windows 3.0) was immune to the vulnerability because the pointer specified in the metafile can only point to data within the metafile, and 16 bit Windows always had a full no-execute-data enforcement mandated by the segmented architecture of 16 bit protected mode. Windows NT for CPU architectures other than 32 bit x86 (such as MIPS, PowerPC, Alpha, Itanium and x86_64) required return-oriented programming to exploit because those architectures had the no-execute functionality missing from older x86 processors.

Computers can be affected via the spread of infected e-mails which carry the hacked WMF file as an attachment. Infection may also result from:

Viewing a website in a web browser that automatically opens WMF files, in which case any potential malicious code may be automatically downloaded and opened. Internet Explorer, the default Web browser for all versions of Microsoft Windows since 1996, does this.

Other methods may also be used to propagate infection. Because the problem is within the operating system, using non-Microsoft browsers such as Firefox or Opera does not provide complete protection. Users are typically prompted to download and view a malicious file, infecting the computer. Infected files may be downloaded automatically, which opens the possibility for infection by disk indexing or accidental previewing.

A free downloadable patch for Windows NT [11] has been provided by Paolo Monti from Future Time, the Italian distributor of Eset's NOD32anti-virus system. The patch works on older operating systems, but it is supplied without warranty.

There have been reports of the official patch being automatically installed even when Windows Automatic Update is configured to ask before installing automatically downloaded updates. This causes an automatic reboot, which can cause loss of data if the user has a program open with unsaved changes.[5]

As a workaround before a patch was available,[6] on 28 December 2005 Microsoft advised Windows users to unregister the dynamic-link library file shimgvw.dll (which can be done by executing the command regsvr32.exe /u shimgvw.dll from the Run menu or the command prompt) which invokes previewing of image files and is exploited by most of these attacks. The DLL can be re-registered after patching by running regsvr32.exe shimgvw.dll. This workaround blocks a common attack vector but does not eliminate the vulnerability.

Guilfanov's website went back online on 4 January in a much-reduced state. No longer providing the patch on-site due to bandwidth issues, the homepage provided a list of mirrors where a user could download the patch and the associated vulnerability-checker, and the MD5checksum for the file, so that it could be checked that a downloaded file was probably genuine.

Microsoft says its patch removes the flawed functionality in GDI32 that allowed the WMF vulnerability. For computers running an unpatched version of Windows, a defence in depth approach is recommended, to mitigate the risk of infection. Various sources have recommended mitigation efforts that include:

According to this SANS Institute Internet Storm Center article, using a web browser other than Internet Explorer may offer additional protection against this vulnerability. Depending on settings, these browsers may ask the user before opening an image with the .wmf extension, but this only reduces the chance of opening the maliciously crafted Windows Metafile, and does not protect against the vulnerability being exploited as these browsers still open the metafile if it is masquerading as another format. It is better to entirely disable image loading in any browser used.

In 2006 Steve Gibson suggested that the peculiar nature of the 'bug' was an indication that the vulnerability was actually a backdoor intentionally engineered into the system.[12] The accusation became an assertion and spread through the internet as a rumor after the technology news website Slashdot picked up Gibson's speculation.[12] The rumor was widely debunked[13][14] and Thomas Greene, writing in The Register, attributed Gibson's mistake to "his lack of security experience" and called him a "popinjay expert."[12]