Earlier I had written that in our preliminary tests, hardware-enforced DEP was effective at blocking the new WMF file exploit. Software-enforced DEP was not.
However, some were having difficulties making it work. In one case, for example, a fellow security researcher had to use a different switch in DEP than we had used. Another had problems getting DEP itself to even work at all, instead having to set a manual switch in the boot.ini file — and even then we’re not sure it stops the exploit.
It’s a pretty important issue, because if hardware-enforced DEP is a way to protect against the exploit, it would put a lot of people’s minds at ease. So fellow security researcher George Ou asked Microsoft, and got a response this evening from a Microsoft spokesperson, which he kindly forwarded to me.
“Microsoft has continued to investigate the use of software-enforced Data Execution Prevention (DEP) to mitigate the Windows Meta File vulnerability for Windows XP Service Pack 2 users. As a result of this investigation, we have updated our guidance regarding DEP to say that some hardware-based DEP, when enabled, can mitigate this vulnerability; however, software-based DEP does not mitigate this vulnerability”
They’ve updated their advisory, and now say the following:
I have DEP enabled on my system, does this help mitigate the vulnerability?
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.
That is fairly useless, but at least they have clarified that, as we’ve earlier stated, software-enforced DEP doesn’t work at all.
Conclusions:
- Software-enforced DEP doesn’t work against this thing.
- Hardware-enforced DEP probably works but don’t count on it. If you’re going to try it, use the option of “Turn on DEP for all programs and services except those I select”. Do not rely on this for protection.
In the end, there are only a few recommendation I can give you for this exploit until Microsoft fixes it.
Basic, easy fixes:
UPDATE: Houston, we have an unofficial hotfix! Install Ilfak Guilfanov’s patch. Link here. CAVEATS HERE.
1. Have AV protection in place. On a budget? See my article, Security on the Cheap, here.
2. To be safe, unregister SHIMGVW.DLL. It is not a perfect fix, though.
3. Run IESPYAD.
IESpyad is a free tool that puts block lists into IE’s restricted sites zone. It’s managed by Eric Howes, who works as a consultant for Sunbelt. We regularly update him with the latest URLs. Click here. 
Additional fixes for the more advanced user:
4. Use our free Kerio firewall with added Snort rules. This is highly effective.
5. If you’re an administrator, filter common file extensions at the perimeter, like BMP, DIB, EMF, etc. See SANS here. Just blocking WMF files is not a full solution, as Windows goes by the header info for the file, not the extension (so one could rename a WMF file to GIF and it would still go through if you weren’t blocking GIF images).
6. It’s not a panacea, but by all means, if you have hardware-enforced DEP, make sure it’s enabled. I would be safe and enable “Turn on DEP for all programs and services except those I select”. In our test systems, it works fine but I wouldn’t bet on it for all systems, and it may not even work with all variants. (If you’re technical and hyper-anal, you could always test for DEP and adjust switches in boot.ini.). Again, this is not a guaranteed fix.
Wow, quite a list, eh?
Alex Eckelberry