Questions about the Microsoft Video ActiveX Control bug

A new zero day critical bug in Windows has been widely reported. Let me summarize things briefly:

The two vulnerable versions of Windows are XP and Server 2003. The safe versions of Windows (just from the perspective of this particular bug) are Vista, Server 2008 and Windows 2000 (with SP4).

The bug is a classic type, view a web page with Internet Explorer, get infected with malicious software. Viewing a web page with Firefox is safe.

All too often, the simple act of viewing a web page can infect a Windows computer. A drastic thing that XP users can do to protect themselves is to run as a limited user. A less drastic way to get the same safety is to use the free DropMyRights program from Microsoft. I blogged extensively about DropMyRights a couple years ago and the advice still stands. 

According to Microsoft, you can not get infected viewing an email message with Outlook or Outlook Express. Just don't click on any links (if your default web browser is not Internet Explorer then clicking links is safe).

The buggy software is referred to by Microsoft as the Microsoft Video ActiveX Control, the MPEG2TuneRequest ActiveX Control Object and file msvidctl.dll. Larry Seltzer referred to it as "the Microsoft Streaming Video control, part of DirectShow".

According to Scott Fulton at Betanews the original purpose of the ActiveX control "was to tune into MPEG2 transport streams -- typically live video streams sent from a server using MPEG2 format." The software, however, is no longer used. Browsers now have plug-ins, such as Windows Media Player and QuickTime, to handle MPEG2 streams.

Information on the problem is scattered in four different web pages on Microsoft' site. Such is the nature of large companies. The pages are:

• Knowledge Base Article 972890 
• Security Advisory (972890)
• Microsoft Security Advisory 972890 Released at the Security Response Center blog
• New vulnerability in MPEG2TuneRequest ActiveX Control Object in msvidctl.dll at the Security Research and Defense blog

Microsoft clearly states that Internet Explorer is vulnerable. Computerworld, Symantec, and others, report that while IE6 and IE7 are vulnerable, IE8 is safe. I reviewed all the documentation on Microsoft's site and nowhere do they say anything about specific versions of Internet Explorer.

BAD NEWS / GOOD NEWS

Bad news: There is no fix for the underlying problem and no estimate for when a fix may be forthcoming.

Good news: Despite this being a critical zero day bug that is currently being exploited, the lack of a patch is no big deal. I say this because, disabling the buggy software is easily done.

Stuart J. Johnston reports that, according to Microsoft, disabling the effected software "does not affect the functioning of applications." In other words, no one was using the software anyway.

THE WORKAROUND

Disabling the buggy software is done by updating the registry, specifically the kill bit for the buggy ActiveX control. The registry updates are complicated though, you need to look for 45 different registry entries (Class Identifiers). Microsoft has automated the registry updates, you can simply download program MicrosoftFixit50287.msi and run it. The process is straightforward.  

MicrosoftFixit50287.msi is available both from the Security Research & Defense blog and from the advisory page.

Interestingly, Microsoft says "While Windows Vista and Windows Server 2008 customers are not affected by this vulnerability, we are recommending that they also set these killbits as a defense-in-depth measure."

This being a Defensive Computing blog, before running the .msi file, I suggest getting its properties and making sure there is a Digital Signatures tab (see above) and that it says it was signed by Microsoft.

Also, since the fix updates the registry, it would be prudent to make a restore point beforehand. When you run the .msi file, it does make a restore point, but it's not obvious whether this is before or after zapping the registry.

Update July 7, 2009: later testing showed that the restore point is prior to the registry updates. However, MicrosoftFixit50287.msi runs just fine if System Restore is disabled, so making a manual restore point is a good way to verify that System Restore is functioning.  

VERIFYING THE FIX

Still more Defensive Computing - did the fix work? Here Microsoft falls down big time. There seems to be no practical way to know. We can't easily verify that the registry was zapped the way it was supposed to have been, or, that zapping the registry actually disabled the buggy code. We just have to trust what Microsoft tells us. Or, use Firefox.

I wouldn't mind if Microsoft said there was no easy, simple or practical way to verify that the fix worked. But no. The Knowledge Base article has a "Did this fix the problem?" section which says "Check whether the problem is fixed." Nothing on how to check. This is insulting.

The part of the registry that gets zapped is

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility

I tried exporting just this section of the registry before and after the zap to see if I could spot the differences. On a new XP SP3 machine, the resulting .reg file was over 1,700 lines. On an old XP SP2 machine, it was over 11,300 lines, much too large for a manual comparison. 

I also looked for a handful of the Class Identifiers specified in the advisory. None were in the registry of my test Windows XP machine. 

And, the zap changes the size of this corner of the registry. On an XP SP2 machine, the exported .reg file had 11,313 lines before the zap and 11,448 afterwards. Why? Beats me, but that's a lot of new bits, killed or not.

MICROSOFT'S GOOF?

On top of the concern about not being able to verify the fix, is the fact that Microsoft made a mistake regarding the registry zap. It might be a trivial mistake or it might be a huge one, I can't tell. I asked Microsoft about this and am waiting to hear back.

When you want to disable the buggy code, you download file MicrosoftFixit50287.msi. Disabling the buggy code is also referred to in the KB article as enabling the workaround (see below). When you want to re-enable the buggy code (that is, disable the workaround), you download file MicrosoftFixit50288.msi. The buggy code is msvidctl.dll.

Simply put, the purpose of MicrosoftFixit50287.msi is to disable msvidctl.dll.

Yet the properties of the file say that it does the exact opposite (see below).

Likewise, the properties of file MicrosoftFixit50288.msi also seem, to me at least, logically backwards. It says that it disables msvidctl.dll, when it actually enables it (what gets disabled is the workaround). 

Are the file properties wrong (a trivial mistake) or did Microsoft mix up MicrosoftFixit50287.msi and MicrosoftFixit50288.msi?

Update July 9, 2009: According to Microsoft, a word was truncated. They said

What you are seeing under the summary tab as the “subject” for the fixit file MicrosoftFixit50287.msi is a truncation of "Enable|Disable msvidctl.dll ActiveX killbits."

If we could verify the zap actually worked, we'd know.

No wonder IE is losing market share.

Updated July 7, 2009 with many small changes such as the addition of DropMyRights and the suggestion to make a restore point before zapping the registry. For more on this topic, see my next posting: More issues with the Video ActiveX Control flaw workaround