NOW SpinRite 6.1 – Fast and useful for spinning and solid state mass storage!

Metafile Image Code Execution

GRC's "MouseTrap" MICE detection utility,
and the facts about Windows Metafile
Image Code Execution

GRC's free MouseTrap utility is compatible with all versions of Windows and the WINE Windows emulator. It determines whether the Windows system under test will execute arbitrary code contained within specially formatted metafile images:

Click to download MouseTrapClick to download MouseTrap

File stats for: MouseTrapfile download  freeware page
Last Updated:
Size: 29k
Jan 19, 2006 at 03:39
(6,751.04 days ago)
Downloads/day: 12
Total downloads: 324,832
Current Rank: 14
Historical Rank: 18

MouseTrapCmd.exe — You may also download a command-line version of our MouseTrap utility. It may be useful for testing older or less compatible builds of the WINE Windows emulator. During our WINE testing, we found that some older builds in active use had trouble with the RichEdit controls used by MouseTrap. So we created a graphics-sparse version for anyone who encounters trouble using the regular GUI-rich MouseTrap.

Listen to Security Now! Episode #23  (29 min)

Any of our weekly Security Now! audio podcasts can always be downloaded as a standard
MP3 file, playable on any PC or media player. Episode #23 describes the contents of this
page, what happened with the WMF vulnerability, "MouseTrap", and what it all means . . .

Right-click on this icon to download and save the high-quality version (14 MB).

Right-click on this icon to download and save the smaller version (3.5 MB).

Facts -vs- Spin

Which versions of Windows have MICE?
Microsoft introduced Metafile Image Code Execution (MICE) in Windows NT4. Every version of Windows starting with NT4, including their not-yet-released Windows Vista (aka Longhorn), incorporated this code. As soon as clever hackers discovered it, Microsoft released patches to remove it. Also remember that any fresh installation of Windows will initially be vulnerable to MICE exploitation until it is patched to eliminate this behavior.

Patches are NOT available for Windows NT4, which continues to have MICE and will forever remain vulnerable. This vulnerability can be suppressed through the use of third-party utilities (see below).

What about Windows 95, 98, 98SE and ME?
Contrary to Microsoft's dynamically changing and frightening statements about the vulnerability of these earlier versions of Windows, they completely lack the MICE facility that was engineered into all later versions of Windows. There is no possibility that any of the earlier versions are vulnerable, and no need for any security patching.

And the Linux/WINE Windows emulator?
You wanted compatibility? You got compatibility! The Windows emulating 'WINE' project made their copy of Windows metafile handling so exact that it, too, inherited this behavior from reverse-engineering and duplicating Windows' operation. Our "MouseTrap" and "MouseTrapCmd" utilities both correctly determine WINE's current vulnerability to MICE. Unpatched and older versions of WINE DO have MICE.

Where can I use MouseTrap?
Our MouseTrap utility works on all Windows platforms, including the Linux/WINE Windows emulation. It will always correctly report on that platform's current MICE — metafile image code execution — status. If MouseTrap says the machine has MICE, it does. If MouseTrap says it does not have MICE, it doesn't.

Does MouseTrap fix Windows?
NO! Our MouseTrap utilities are only MICE reporting tools. If you are using any version of Windows after (but not including) NT4, Microsoft's latest security patches should be used to remove the MICE. If you are using Windows NT4, or cannot apply Microsoft's patches, you may use one of the MICE "vulnerability suppressor" utilities written by others. See the "How to rid your Windows of MICE if Microsoft won't patch" section near the bottom of this page.

Was MICE added to Windows intentionally?
Software engineers who have looked closely at the Windows code that enables the MICE capability have concluded that, for whatever reason, it is operating exactly the way its designers intended it to.

Mark Russinovich, well known professional developer at SysInternals, performed his own examination, the results of which he sent to both Microsoft and me (which you can read in full here). Mark concluded:

"The bottom line is that I'm convinced that this
  behavior, while intentional, is not a backdoor."

Mark agreed that Windows MICE behavior was intentionally incorporated into Windows. I respect the fact that he chose not to characterize it as a "backdoor", since that term carries such malicious connotation, and no one believes (myself included) that Microsoft would act in a deliberately malicious manner. But despite Mark's wishing to avoid characterizing this intentional facility as a "backdoor", the entire personal computer industry freaked out as much as it ever has when the power of MICE became public knowledge.

It was certainly usable as a "backdoor".

Another professional developer and industry associate with a great deal of reverse-engineering and low-level systems programming experience wrote to me, which I quote with his permission (emphasis is his):

"I've learned more and talked this over with peers. I think your argument is MUCH more convincing than Microsoft's explanation; though if this back door is intentional, the Microsoft guys answering the accusations likely don't know anything about it ;).

The idea of it being intentional has met considerable resistance by people when they first hear of it, and even I was originally resistant. But when people learn all the facts they grow surprisingly less resistant ;). One guy said, "its not like it's a jmp eax".. which is ironic, since that's EXACTLY what it is."

What is it that programmers see?
Many programmers who took the trouble to look into the operation of MICE concluded that it was intentionally added to Windows because the instructions that cause the computer's processor to "jump" into the metafile image and begin executing instructions are plain as day. Sometimes computer code is obscure and unclear, especially when it is reverse-engineered. But this is not. Any unbiased examiner would look at Microsoft's code and conclude that someone, for some reason, wanted to give Windows the ability to execute code contained within metafile images . . . just as Windows has starting with NT4.

If this is so obvious, how did Microsoft miss it?
That is the million dollar question. We know that earlier versions of Windows did not have this facility and that all versions of Windows since NT4 have. It was even already incorporated into the next "Vista" version of Windows. Somehow, despite having been resident in Windows for nearly ten years, despite many security sweeps and analyses looking for exactly these sorts of things, and even despite several past security vulnerabilities occuring right there in the Windows metafile processing code . . . Microsoft never removed this facility until it became public knowledge.

We must assume that Microsoft either wanted this code to remain in Windows, or just continually missed noticing it.

But if it's clearly there intentionally, who put it in?
Only Microsoft knows.

Why did they put it in?
Only Microsoft knows.

What does Microsoft say about all this?
Microsoft said nothing whatsoever, beyond their standard "vulnerability disclosure" for several weeks. Everyone in the computer industry has become so accustomed to these continual security updates and patches that no one thought twice . . .

Until I posed some serious questions about what was going on with Leo Laporte during our weekly Security Now! podcast episode #22. Given the preliminary evidence and "feeling" I had from starting to write the freeware utility that evolved into "MouseTrap", I told our Security Now! audience that this "felt" like a deliberate backdoor.

A bit of WMF technical background:
In order to make sense of what follows, we need a bit of technical terminology:

A Windows metafile is composed of a series of drawing commands which windows "interprets" in a linear series from first to last. In doing so, it draws an image into a drawing space known as a device context. The device context holds information about the current state of the drawing, such as its size, the current color and thickness of its drawing pen, etc.

To extend the power of metafiles, Microsoft added an "Escape" command to allow an assortment of non-drawing functions to be intermixed. Examples include things like Escape/STARTDOC and Escape/ENDDOC to be specified within the metafile.

The source of the recent WMF controversy is the "Escape/SETABORTPROC" command which allows the metafile to specify an application-provided subroutine which Windows could call to provide feedback to the program while Windows was reading and processing the metafile.

Quoting from Microsoft's MSDN archive page for Windows 3.0 and 3.1, dated 1992:

"The SetAbortProc function (and the SETABORTPROC escape) sets up what is known as the AbortProc. This AbortProc function resides in the application; GDI calls it during a print job to inform the application of spooler errors and to allow the application to abort the job when desired."

(Emphasis added above by me, see a screen image of the actual page or display the whole page with the MSDN archive link above.)

The CRUCIAL POINT for this entire debate is that NO ONE at Microsoft EVER stated or documented that the AbortProc code could or should reside inside a metafile image. As you can see stated very clearly above, "This AbortProc function resides in the application": this is what was changed in later versions of Windows.

What's more, the proper design of the SETABORTPROC function makes it impossible for a static metafile image to access itself. Since it has no idea where it will be loaded into memory, it cannot possibly contain a previously-specified pointer to itself.

But as we have seen, with the design of NT4 and all subsequent NT operating systems, Microsoft silently changed the operation of the metafile's SETABORTPROC function — contrary to all documentation and reason — to create this "in image" code execution capability, or "MICE" as I call it. (And programmers who have independently examined the code agree that what's there is intentional.)

Microsoft Responds 

Toward the end of the day following Security Now! episode #22, Microsoft's Security Research Center (MSRC) posted a "blog page" which was clearly a reply intended to address the points I had raised during the podcast. You can see the entire blog as it was posted with this MSRC link.

Since it is quite lengthy, I am going to excerpt pieces from it and respond in-line to just some of what it states. Please read the entire original blog posting in order to understand Microsoft's entire official position:

Excerpts and comments from Microsoft's MSRC January 13th, 2006 blog posting:

Stephen Toulouse, for Microsoft:
"The vulnerability was introduced when all that GDI functionality was allowed to be called from metafiles."

This is very misleading. There is nothing inherently vulnerable about metafiles. This is demonstrated by the fact that all proper metafile processing works just fine today, after Microsoft patched Windows to remove the previously hidden MICE behavior.

The TRUTH is that "the vulnerability" was introduced when Microsoft silently changed a function in metafile processing to allow execution of image code. After it became public knowledge they changed it back, and all is well.

"The potential danger of this type of metafile record was recognized and some applications (Internet Explorer, notably) will not process any metafile record of type META_ESCAPE, the overall type of the SetAbortProc record. That restriction is the reason it's not possible to exploit this vulnerability by simply referencing an image directly in HTML. IE just won't process it."

Okay . . . So now Microsoft says that they already knew about the "potential danger of this type of metafile record", but — for some unexplained reason — they chose not to fix it, as they have now done. Instead, they told Internet Explorer not to process those "potentially dangerous" metafile records.

The TRUTH is that none of these "potentially dangerous" Escape functions are needed inside metafile images at all, as proven by the fact that Internet Explorer has never processed them. And neither are they truly dangerous when they are written to function as specified and documented (and as they originally did operate).

But, again, rather than remove these functions, which Microsoft says they believed were dangerous, they not only remained inside Windows, but were intentionally altered, as we saw above, to allow metafiles to run executable code. (For some reason, Microsoft MADE them dangerous.)

"Now, there's been some speculation that you can only trigger this by using an incorrect size in your metafile record and that this trigger was somehow intentional. That speculation is wrong on both counts. The vulnerability can be triggered with correct or incorrect size values. If you are seeing that you can only trigger it with an incorrect value, it's probably because your SetAbortProc record is the last record in the metafile. The way this functionality works is by registering the callback to be called after the next metafile record is played. If the SetAbortProc record is the last record in the metafile, it will be more difficult to trigger the vulnerability."

Yep, I got that wrong. Stephen Toulouse and Microsoft are completely correct on this count.

My original vulnerability test metafile contain only a single SETABORTPROC record. Mark Russinovich also independently confirmed that this was the reason for what I encountered in my preliminary experiments. (See Mark's eMail to me.)

GRC's "MouseTrap" and "MouseTrapCmd" utilities use a six-record metafile where setting proper lengths for the metafile records works as expected and successfully triggers the metafile image code execution behavior.

"With WMF we want to be very clear: the Windows 9x platform is not vulnerable to any "Critical" attack vector. The reason Windows 9x is not vulnerable to a "Critical" attack vector is because an additional step exists in the Win9x platform: When not printing to a printer, applications will simply never process the SetAbortProc record. Although the vulnerable code does exist in the Win9x platform, all "Critical" attack vectors are blocked by this additional step."

This conclusion to the MSRC blog posting is the most confusing and disingenuous set of statements of all. Microsoft MUST know what I and others have determined after careful examination of Windows 9x: All systems before Windows NT are absolutely not vulnerable to abuse of the SETABORTPROC function because in all those earlier systems it works the way the documentation states, and is incapable of running code in a metafile image. Does Microsoft hope to deliberately frighten the millions of people who are still happily using Windows 9x into upgrading to newer operating systems?

Microsoft also states that Windows 9x platforms are "not vulnerable to any 'Critical' attack vector" because they take additional protective steps. This would lead any reasonable reader to ask why the later, now-vulnerable versions of Windows have had these beneficial "additional protective steps" removed?

What Does It All Mean?

Couldn't this have all been a mistake?

Of course,  sure,  absolutely,  probably was.

It could have been a mistake that all newer versions of Windows (including the not-yet-released beta version of Vista) ever since NT4, had the extra protective code removed, which was present in the earlier Windows 9x platforms.

And it's possible that the official, logical, and documented operation of the SETABORTPROC Escape function was mistakenly changed from its traditional safe operation, which was never capable of running code contained within a metafile, to its new operation which experts agree appears to have been intentional.

And it's possible that Microsoft doesn't understand the way Windows 9x works, and that they truly believe that those legacy platforms are vulnerable to metafile image code execution, against all evidence to the contrary.

As the saying goes . . . anything is possible.

So . . . that's it?

Yes, that's it.

I, and a large number of terrific researchers who participate in our newsgroups, became involved with this issue when it appeared that the older legacy versions of Windows would be in need of some sort of permanent security patching which Microsoft had said they were not going to provide. (Because the danger was not sufficiently severe.) So I was going to design a permanent patch for the millions of users who are still happily using Windows 9x systems.

But I became curious when I saw the exact operation and nature of this Windows "flaw." It was unlike any others I had ever seen. As I researched further I became increasingly skeptical about that number of compounding coincidences that all needed to line up for Microsoft's shifting stories to make sense.

It is clear that we will never know who knew what within Microsoft, or whether even Microsoft themselves know.

However, as a result of this research we can firmly state that, despite Microsoft's apparent scare tactics, users of the Windows 9x family have absolutely nothing to fear from MICE, and users of Windows NT should be aware that their Windows systems have MICE.

And, of course, as a result of this research, GRC is now able to offer a new and valuable piece of freeware: The MouseTrap and MouseTrapCmd utilities to reliably detect when any instance of Windows has "MICE" and would be vulnerable to Windows metafile image code execution.

How to rid your Windows of MICE if Microsoft won't patch . . .
This NOD32 page contains links to Paolo Monti's recommended "WMF patch" MICE vulnerability suppression program. It must be installed and running to remove Windows MICE behavior in any unpatched versions from NT4 and later. Its installation and removal does NOT require a system reboot.
This is Ilfak Guilfanov's page containing a link to download Ilfak's original "world saving" patch which protected millions of computer users who were waiting for an official patch from Microsoft. It must be installed and running to remove Windows MICE behavior in any unpatched versions from NT4 and later. Its installation and removal does require a system reboot.
"Patching" Notes: Our free "MouseTrap" utility will ALWAYS correctly show you whether your system currently has MICE. If MouseTrap says you have MICE, then you need to install a Microsoft patch if you can (remember to reboot afterward), or one of the other patches listed above. Once any of the patching solutions is properly applied, MouseTrap will indicate that your system has NO MICE.

"MouseTrap" version history
 [1.0.2210.2] — First public release.
 [1.0.2210.3] — Added Authenticode digital signature.

"MouseTrapCmd" version history
 [1.0.2210.0] — First public release.
 [1.0.2210.1] — Added Authenticode digital signature.

Jump to top of page
Gibson Research Corporation is owned and operated by Steve Gibson.  The contents
of this page are Copyright (c) 2024 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy.
Jump to top of page

Last Edit: May 04, 2013 at 18:12 (4,088.44 days ago)Viewed 61 times per day