|
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: |
|
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:
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. 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):
| ||||
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. |
|
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:
|
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. |
How to rid your Windows of MICE if Microsoft won't patch . . .
|
"MouseTrap" version history
|
"MouseTrapCmd" version history
|
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. |
Last Edit: May 04, 2013 at 18:12 (4,176.45 days ago) | Viewed 47 times per day |