It was inevitable. A third party (ZERT) has issued a patch for the VML vulnerability in IE.

I can’t recommend this patch because I haven’t tested it nor do I know anything about ZERT.

However, this does emphasize the severity of this vulnerability. Its frustrating to me that with an application as widely distributed and used as IE, Microsoft isn’t quicker to the punch with releasing patches. Patches are by design reactive security. However, Microsoft is making them even more so by waiting until there is a wide-scale impact before they’ll rush a patch.

Although it wasn’t my idea, I’m a huge proponent of a ‘beta patch program’ from Microsoft that allows them to release patches rapidly, while not performing 100% regression testing. In some cases I would most certainly weigh wide-scale compromise as more important than wide-scale application problems in my network. I want that choice and Microsoft is not letting me have it. They are making that decision for me.

My recommendation for situations like this is to start doing the work now to get your network weaned off patches as your primary means of security. Listed below are some things you can do:

1. Deploy NIPS (network intrusion prevention systems). They’ve come a long way from the early IDS days of Snort, etc. Get a well-reputed IPS that uses hybrid detection techniques. Invest the money now.
2. Deploy HIPS (host intrusion prevention systems) to at least your laptops.
3. Firewall all machines on the network. Even a basic firewall configuration that allows all comms to the servers and no comms between workstations will help tremendously.
4. Defang IE. Web attacks are quickly becoming the exploit vector du jour…
   • Implement the steps I mentioned in this page. (I’ll be merging everything soon)
   • Disable ITS amd MHTML protocol handlers per CERT
   • Unregister the HCP protocol from IE (help and support center)
   • Disable Windows Scripting Host via a login script (do this if you don’t use windows scripting host to manage your hosts)
   • Proactively disable known Active X controls. There used to be a regularly maintained killbit file but they’ve since pulled that service. I have the file from February ’06 here.
5. Remove local admin rights from users if they have it. This prevents several actions that many malware attempt, such as:

   - Creating files in the system32 directory.
   - Terminating various processes.
   - Disabling the Windows Firewall.
   - Downloading and writing files to the system32 directory.
   - Deleting registry values in HKLM.

For more information about this topic

• No Related Post