Lots of bad advice for critical WMF vulnerability!

[Updated again at 12/31/2005 1:45 AM]  There has been a lot of bad information/advice being kicked around on the Internet pertaining to the critical WMF vulnerability in the last few days.  I'm said to admit that I too fell for it for a short period of time until I proved that these "fixes" were worthless.  To verify these claims, I went to websites known for distributing spyware.  In both cases for the Registry Modification and hardware DEP protection, my computer was instantly flooded with popups and warning messages and Process Explorer showed a dozen or more processes and netsh commands secretly destroying my test machine.

I tested the registry modification from Mr. Athias that was suppose to mitigate the WMF vulnerability attack.  For safety purposes, I ran the test from a VMWare Windows XP SP2 guest.  The virtual machine was fully patched with Windows XP SP2 and the registry was modified as Mr. Athias suggested yet it was completely trashed by spyware.  The spyware infections were so nasty that I had to completely destroy and rebuild eight virtual Windows XP machines to verify the results.  The registry modification from Mr. Athias simply won't protect you.

In addition to the registry modification, our own Suzi Turner pointed me to Alex Eckelberry's blog which claims that Windows DEP (Data Execution Prevention) and hardware Execute Disable support on the CPUs could mitigate this WMF vulnerability.  Unfortunately, my tests showed that DEP does not protect you against this WMF vulnerability as Eckelberry claims.  My virtual machines were infected over and over again even though hardware DEP was enabled.  [Update:  After chatting with Alex Eckelberry, it's clear that Alex was getting conflicting results from mine.  Both Alex and PCDoctorGuide were able to get hardware DEP working on the default Windows DEP settings while it didn't protect me.  My tests show that the default settings for hardware-enforced DEP do not work but turning on hardware-enforced DEP for all programs did work.]

[Updated again on Microsoft's DEP advice:  Microsoft has said that just using Software-enforced DEP helps to mitigate this WMF flaw.  After I contacted Microsoft, A Microsoft spokes person admits that software-enforced DEP does not work and informed me that the original advisory has been updated.  Here is the actual text of the original advisory and updated advisory:

Original advisory:
"I have software DEP enabled on my system, does this help mitigate the vulnerability?  Yes. Windows XP Service Pack 2 also includes software-enforced DEP that is designed to reduce exploits of exception handling mechanisms in Windows. By default software-enforced DEP applies to core operating system components and services. This vulnerability can be mitigated by enabling DEP for all programs on your computer.  For additional information about how to “Enable DEP for all programs on your computer”, see the product documentation."

Modified advisory as of 12/30/2005:
"Software based DEP does not mitigate the vulnerability. However, Hardware based DEP may work when enabled: please consult with your hardware manufacturer for more information on how to enable this and whether it can provide mitigation."

While it's great Microsoft responded to my request to fix their advisory the same day on a Friday before New Years Day Weekend, they should not have taken out the last two sentences in the excerpt above.  They should have left the following portion in:  "By default software-enforced DEP applies to core operating system components and services. This vulnerability can be mitigated by enabling DEP for all programs on your computer.  For additional information about how to “Enable DEP for all programs on your computer”, see the product documentation."  Even though Alex Eckelberry got conflicting results that shows the default Windows XP SP2 DEP settings stops this WMF exploit, my results showed you had to go the extra mile of enabling DEP for all programs on your computer.  Microsoft still needs to clarify this and explain why the default DEP settings work sometimes and not others.  But for now, the safe thing to do is to modify the DEP settings to apply to all programs.  Hardware-enforce DEP versus software-enforced DEP is explained here nicely and Alex include screen shots to help you determine if you're running hardware or software DEP.

The default setting on Windows XP SP2 for DEP only protects core Windows components and not extra applications like the "Windows Picture and Fax viewer" (I can't blame Microsoft for this Windows XP SP2 default setting because they were damned if they did and damned if they didn't.  There was a lot of sensationalist bashing against SP2 breaking applications even though it was nothing more than a firewall port being blocked and the end result was that many people to this day are still afraid to install SP2 on their computers.)  By setting DEP to the "opt-out" setting where DEP is on by default for every application unless otherwise specified, there may be some legitimate applications that break.  You'll need to manually put those legacy applications in the exclusion list but demand that the software vendor provide an update to support DEP.

There are some reports that I've been hearing where people can't even get their hardware-enforced DEP to work but there may be some special circumstances and I have not been able to verify it.  Dave Methvin from PCPitStop had problems getting his Athlon 64 3400+ to work unless he manually set his boot.ini file to turn DEP to the always on setting using "set /noexecute=AlwaysOn".  This is not very practical because it doesn't allow for any manual exceptions.  My own tests with an Intel Pentium 4 630 3.0 GHz CPU show that hardware-enforced DEP does work when it's set to "Enable for all programs and services except for those I select".  In my case, I can make exceptions to legitimate legacy applications that don't work with DEP protection.  It's important to note that DEP mitigates these types of attacks and should only be used as an extra layer of protection in addition to other defenses.]

[Updated again:  Microsoft's official workaround to unregister a certain DLL file using the command of "regsvr32 /u shimgvw.dll" at the Start-Run prompt seems to also be very effective.  Unfortunately, it kills the ability for Windows Explorer to display thumbnail images but I'm afraid we'll have to live without it until an official patch from Microsoft comes out (hopefully next month's patch cycle).  There are new reports that there are certain cases where this fix doesn't work.  MSPaint and Lotus Notes can still be exploited even with this DLL unregistered.  I think we haven't heard the end of this one yet and there may be many more applications vulnerable to this exploit but the combination of hardware-enforced DEP and unregistering the shimgvw.dll file seems to be very effective for now.]