Unless you’ve been on holiday leave you’ve probably heard about the WMF vulnerability by now. Everything seems to indicate that Microsoft won’t take action to patch this gaping hole before January 9th, so here are a few measures to be on the safe side.
1. Before you do anything else, go ahead an unregister SHIMGVW.DLL
C:\> regsvr32 -u %windir%\system32\shimgvw.dll
Put this in a login script, and just for good measure go ahead an run it in every Windows box you’re responsible for. Heck, run it even in those you’re *not* responsible for as well.
2. I already got quite a few .WMF attachments on the spamtraps. F-Secure has a very interesting specimen and a lot to say about it. So the next step is to block them in exim.conf. Enable the acl_check_content ACL and make sure that you have a rule like this one:
deny message = This message contains an unwanted file extension ($found_extension)
demime = scr:vb:vbs:vbe:js:jse:reg:bat:lnk:pif:hlp:dll:com:rar:wmf
3. SquidGuard can filter URLs that match a given regular expression. Add these regexes to a local-blocks/expressions or similar file:
http://.*\.(scr|vb|vbs|vbe|jse|reg|bat|lnk|pif|hlp|com|rar|wmf)($|\?) ftp://.*\.(scr|vb|vbs|vbe|jse|reg|bat|lnk|pif|hlp|com|rar|dll|js|wmf)($|\?)
Note that the .dll and .js extensions aren’t blocked for HTTP. That’s because the lovely IIS uses the .dll suffix for its extensions, and you can’t block JavaScript for HTTP either unless you want to break 90% of the Internet for all your local clients. I firmly belive that blocking them for FTP is just fine, tough.
Update 20060102 125530: Jeremy Gaddis shares a squid recipe.
Of course, this only applies if you use exim and Squid+SquidGuard -which by the way are all excellent Open Source products- but the same principle applies to any other mail and proxy servers. If you implement all three recommendations you should be fine. User should not get .WMF files through email or the Web. Even if a clueless user catches it though some other means (IM, external e-mail account, a *ack!* floppy disk/CD-ROM/flash drive, a helpful colleage, etc.) the REGSVR32 workaround should keep the exploit at bay. If you definitely need to work with WMFs, there are other alternatives as outlined by Richard Bejtlich. Just don’t hold your breath for a Microsoft-backed patch.
<rant>And about Microsoft’s “swift” response to this issue: The next time that someone gives me the line about not using Open Source because there’s nobody to take responsibility for problems, I’ll puch him in the face without further warning.</rant>