Security Research & Defense

Information from Microsoft about vulnerabilities, mitigations and workarounds, active attacks, security research, tools and guidance

July, 2009

  • Announcing OffVis 1.0 Beta

    We’ve gotten questions from security researchers and malware protection vendors about the binary file format used by Microsoft Word, PowerPoint, and Excel. The format specification is open and we have spoken at several conferences (1, 2, 3) about detecting malicious docs but we wanted to do more to help defenders. So earlier this year we started working on an Office Visualization Tool called “OffVis”. We first shared the tool with our MAPP partners in May and have now released it as a no-charge download from the Microsoft Download Center for everyone to benefit from this work. We have also recorded a 30-minute training video that describes the file format. We will announce the video here on the blog when it is ready to be released.

    OffVis displays an OLESS-based binary files in two ways. It shows a hex view of the raw file contents on the left side of the window and the tree of objects built up from parsing those raw file contents on the right side of the window. You can see an example below.

    (click to expand)

    Double-clicking on a specific byte in the hex view will navigate the tree view to the object that byte belongs to. Double-clicking an object in the tree view navigates the hex view to the bytes that make up the object (and any of its child objects).

    OffVis also detects eight Office file format vulnerabilities that we have seen exploited over the past couple years. We chose these specific CVE’s to detect based on prevalence of attacks in the wild. As was discussed in our last Security Intelligence Report, most attacks use vulnerabilities for which a security update has been available for months. We hope this “known-bad” detection will help you analyze suspicious documents that arrive into your network. And if you find malicious samples exploiting product vulnerabiltiies that are not detected , please send them to us so we can consider adding detection to OffVis for more vulnerabilities. We want to keep the correct balance between giving defenders more information to help them detect attacks and keeping vulnerabilities away from attackers. Here’s the initial list of CVE detection included:

    CVE Product Bulletin
    CVE-2006-0009 PowerPoint MS06-012 (March 2006)
    CVE-2006-0022 PowerPoint MS06-028 (June 2006)
    CVE-2006-2492 Word MS06-027 (June 2006)
    CVE-2006-3434 Word MS06-062 (October 2006)
    CVE-2007-0671 Excel MS07-015 (February 2007)
    CVE-2008-0081 Excel MS08-014 (March 2008)
    CVE-2009-0238 Excel MS09-009 (April 2009)
    CVE-2009-0556 PowerPoint MS09-017 (May 2009)

    In the screenshot below, you can see an OffVis CVE-2009-0556 detection. The PST_OutlineTextRefAtom atom at file offset 766378 has a Type value of 3998 (0xf9e), triggering the detection.

    You can find out more about OffVis by downloading it from the Microsoft Download Center and viewing the readme file. Please email us at switech at if you have questions, comments, or malicious samples that are not detected.

    Thanks to Kevin Brown, Dan Beenfeldt, and the rest of the MSRC Engineering team who worked on this project!

    Update Sept 18, 2009: This initial version of OffVis requires .Net framework 3.5.  If you encounter errors about being unable to load assembly System.Core version 3.5, please install .Net framework 3.5.  The next public release of OffVis will be linked against .Net framework 2.0 which we expect is more widely deployed.

    - Jonathan Ness, MSRC Engineering

    *Posting is provided "AS IS" with no warranties, and confers no rights.*

  • Overview of the out-of-band release

    Today we released Security Advisory 973882 and with it, two out-of-band security bulletins. These updates are MS09-034 (an Internet Explorer update) and MS09-035 (a Visual Studio update). At this time for customers who have applied MS09-032 we are not aware of any “in the wild” exploits that leverage the vulnerabilities documented in 973882 and MS09-035. However, MS09-034 and MS09-035 work together to build further defenses against the known vulnerabilities in ATL.

    Why release these security updates out-of-band?

    While the vulnerability has been known to Microsoft for some time, additional information regarding these vulnerabilities has been growing over the past few weeks. And with the Black Hat and Def Con security conference getting people together around the same watering hole, natural curiosity means that risk to customers could increase as more information is disclosed. We’ve seen one active attack on an ATL vulnerability targeting the msvidctl.dll control. While all known attacks have been blocked with the release of MS09-032, rather than waiting for more risk and attacks on ATL vulnerabilities, we decided to proactively release these security updates to help protect customers and mitigate the risk in a more controlled manner. We believe the right thing to do is to help protect customers with out-of-band security updates in this unique situation where we anticipate the risk will increase before our next scheduled security update opportunity.

    Why release two separate security bulletins?

    The two security updates together address separate CVEs but are being addressed out-of-band because they are related. Allow me to explain:

    The relevant CVEs warranting the out-of-band release are included in the Visual Studio bulletin (MS09-035) CVE-2009-0901 and CVE-2009-2493 (ATL header and libraries update), and are also discussed in Security Advisory 973882. These are the vulnerabilities in the ATL that could be exposed in various controls and are currently being discussed publicly. However, we’ve also released an Internet Explorer update. This is being released to help protect customers while developers update their controls as defense-in-depth measures in Internet Explorer that help prevent exploitation of all known ATL vulnerabilities discussed above. There are 3 other CVEs in the IE bulletin, but they aren’t related to the ATL issues. They’re included because Internet Explorer updates are cumulative, and separating them out from this release would have delayed the ability to release the defense-in-depth measures.

    The bottom line, the CVE’s discussed in the Visual Studio Bulletin (MS09-035) and the ATL issues covered in Security Advisory 973882 create a level of risk which necessitates the out-of-band release.

    What are the ATL vulnerabilities?

    While there are several vulnerabilities described in Security Advisory 973882 and MS09-035 the vulnerability we think will get the most discussion is one in ATL that allows COM object instantiation despite the killbit security check. As many of our readers remember from our previous killbit-related blog posts, the killbit is a protection mechanism useful for blocking the use of vulnerable controls. Our most recent use of the killbit was to block MSVidCtl.dll from being loaded in Internet Explorer in MS09-032. So the ability to get past this important part of ActiveX security could allow an attacker to again be able to, for example, force MSVidCtl.dll to be loaded in Internet Explorer. Of course, a customer would first need to have another vulnerable control on the system for this security to be bypassed, and with the Internet Explorer update (MS09-034) we’ve blocked known ways for attacks to exploit this issue when customers are browsing the internet.

    What do the two updates do?

    MS09-035, the Visual Studio security update, provides the updated public ATL. The Visual Studio team released a resource page article with detailed instructions that developers can use to assess whether their controls are vulnerable and what changes to make to help secure their controls.

    We have been working with major third party software vendors, helping them understand this problem and get fixes ready for their controls. More information on that can be found in our Microsoft EcoStrat Blog post here.

    Also, as previously mentioned, to help protect customers while developers update their controls, we are releasing an Internet Explorer security update (MS09-034). This update includes new defense in depth protects that help mitigate IE loading and instantiating controls that contain the ATL vulnerabilities. Dave Ross wrote more detail about this IE mitigation.

    Summary of guidance

    Microsoft has released a lot of guidance today. Here is a summary with links:


    First, apply MS09-034, the Internet Explorer security update. This update will help keep you safer from attacks attempting to leverage the ATL vulnerabilities (like the already fixed MSVIDCTL one). Second, if you are a software vendor and ship controls built using the vulnerable ATL headers, please review the Visual Studio team's guidance to determine whether your control is vulnerable and ship an updated version if needed.

    We would be happy to ship a killbit so if you would like on please send your request to

    Finally, send us any questions you have to

    - Jonathan Ness, MSRC Engineering
    *Posting is provided "AS IS" with no warranties, and confers no rights.*

  • Internet Explorer Mitigations for ATL Data Stream Vulnerabilities

    IE security update MS09-034 implements two defense-in-depth measures intended to mitigate the threat of attacks which attempt to exploit the Microsoft Active Template Library (ATL) vulnerabilities described in Security Advisory 973882 and MS09-034. We would like to explain these mitigations in more detail.

    ATL persisted data checks

    The first mitigation is a change to modify how ATL-based controls read persisted data by detecting specific call patterns that are problematic. One such example is the call pattern that led to the MSVidCtl.dll exploit addressed by MS09-032, one of the security updates released on July 14th. Furthermore, the mitigation addresses the ATL vulnerabilities addressed by, and described in, MS09-035.

    The change is on by default for all affected platforms that have installed MS09-034, and will block all known ATL vulnerabilities for any controls loaded in Internet Explorer (even those not created by Microsoft.) We anticipate limited application compatibility problems with this defense in depth change. For this reason we encourage customers to test and deploy MS09-034 right away to block potential attacks on vulnerable controls.

    Controlling the usage of specific interfaces (potential application compatibility impact)

    MS09-034 also introduces a second defense-in-depth mitigation on the vulnerable platforms. This mitigation is off by default, because it is a “heavy hammer” that prevents the Web Browser control from initializing controls using the IPersistStream* and IPersistStorage interfaces. In essence, this mitigation addresses the ATL vulnerabilities by preventing the overall usage of the potentially dangerous interfaces rather than specific call patterns that occur as those interfaces are exercised.

    We encourage application developers that host the Web Browser Control to opt-in to this mitigation using the new FEATURE_RESTRICT_OBJECT_DATA_ATTRIBUTE Feature Control Key.

    The FEATURE_RESTRICT_OBJECT_DATA_ATTRIBUTE key is currently off by default because many controls are known to load persisted data using IPersistStream* and IPersistStorage in scenarios which are understood to be by design. Any place where a control is loaded via an OBJECT tag and where the DATA attribute is used in that OBJECT tag is a scenario that this mitigation could potentially impact control functionality and compatibility.

    For example, the mitigation could prevent the expected operation of the following OBJECT tag:

    <object classid="clsid:…" DATA=””>

    In order to enable this Feature Control Key, follow these steps:

    • Open HKLM or HKCU\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl key in the registry.
    • Create a subkey for FEATURE_RESTRICT_OBJECT_DATA_ATTRIBUTE, if it doesn't already exist.
    • Add a new REG_DWORD value for a process name, or * to opt-in all processes, and set its value to 1.

    As an example, the following registry value opts in to the FEATURE_RESTRICT_OBJECT_DATA_ATTRIBUTE Feature Control for all processes:

                   Internet Explorer
                                       * = 0x00000001

    Individual controls which have been determined to not be vulnerable to the attack using IPersistStream* and IPersistStorage can opt-out of the mitigation by using a new ActiveX Compatibility Flag DWORD value:

                   Internet Explorer
                        ActiveX Compatibility
                             {CLSID of ActiveX control}
                                  Compatibility Flags = 0x02000000

    Keep in mind that the Compatibility Flags value for any given control is a bit field, so be careful not to blindly overwrite the value or remove it, so as not to erase a Kill-Bit.

    You can implement the “heavy hammer” approach described in the earlier example to opt-in all processes with the understanding that certain scenarios and line of business application might break. To help customers more easily turn on the second defense in depth change we are providing the below FixIt packages.

    Enable user specific Feature Control Key for all processes (HKCU will be changed)

    Disable user specific Feature Control Key for all processes (HKCU will be changed)

    Enable system wide Feature Control Key for all processes (HKLM will be changed)

    Disable system wide Feature Control Key for all processes (HKLM will be changed)

    - David Ross, MSRC Engineering

    *Posting is provided "AS IS" with no warranties, and confers no rights.*

  • ATL vulnerability developer deep dive

    This morning we released MS09-035 to address ATL vulnerabilities in Visual Studio. This blog post will help you answer the following questions:

    • What are the ATL vulnerabilities? Which versions of ATL are vulnerable?
    • How can I tell if my ActiveX control is affected?
    • How can I fix a vulnerable control?

    What are the ATL vulnerabilities? Which versions of ATL are vulnerable?

    There are three ATL vulnerabilities discussed in the bulletin:

    • CVE-2009-2493: Remote code execution which is caused due to instantiation of arbitrary objects which can bypass related security policies such as the killbit.
    • CVE-2009-2495: Information disclosure.
    • CVE-2009-0901: Remote code execution which is caused due to VariantClear() call on a variant that was not correctly initialized.

    The following table tells which versions of ATL are affected by each bulletin.

      CVE-2009-2493 CVE-2009-2495 CVE-2009-0901
    Visual Studio 2002 SP1 (out of support) Yes Yes Yes
    Visual Studio 2003 SP1 Yes Yes Yes
    Visual Studio 2005 SP1 ** Yes **
    Visual Studio 2008 RTM ** Yes **
    Visual Studio 2008 SP1 ** Yes No
    Visual Studio 2010 Beta No No No

    ** Controls and components built with Visual Studio 2005 SP1 and Visual Studio 2008/SP1 may be less affected because a new safe macro PROP_ENTRY_TYPE[_EX] was introduced in Visual Studio 2005 SP1. This new macro solves the problem almost entirely. Furthermore, starting with Visual Studio 2008, the PROP_ENTRY unsafe macro was deprecated. Thus, controls and components built using Visual Studio 2008/SP1 are less likely to be vulnerable. For further information review this resource article.

    Several things we would like to clarify here:

    • Visual Studio itself is not vulnerable. Instead, controls and components built with the vulnerable ATL headers may be impacted and similarly, users with such controls and components installed may be subject to attack.
    • If you have built a control or component based on an affected ATL version, your control or component may be vulnerable. There are several conditions that are needed to reach the vulnerable ATL code which are discussed later on in this blog post.
    • These vulnerabilities apply to any control or component built with ATL if the necessary conditions are present.

    How can I tell if my control is affected? How can I fix it?

    You need to review the source code of your control or component. Please refer to the detail guidance in the following resource article.

    Do I need to issue a killbit/phoenix bit for older controls?

    If you decide there is no reason for your control to be ever hosted in IE, please consider issuing a killbit for it. For more information about the killbit, please refer to SRD “killbit” blog series. Microsoft, for example, issued the killbit as the final fix for the msvidctl.dll issue (MS09-032).

    If you decide to fix the vulnerable control, we highly encourage you to issue a killbit for the old control and a phoenix bit for the updated control. The Kill-bit FAQ three part series explains this in detail.

    The Kill-Bit FAQ: Part 1 of 3

    The Kill-Bit FAQ: Part 2 of 3

    The Kill-Bit FAQ: Part 3 of 3

    - Arthur Wongtschowski, Windows Sustained Engineering
    - Chengyun Chu, MSRC Engineering

    *Posting is provided "AS IS" with no warranties, and confers no rights.*

  • MSVIDCTL (MS09-032) and the ATL vulnerability

    Today we have released Security Advisory 973882 that describes vulnerabilities in the Microsoft Active Template Library (ATL), as well as security updates for Internet Explorer (MS09-034) and Visual Studio (MS09-035). The Visual Studio update addresses several vulnerabilities in the public versions of the ATL headers and libraries. The IE update contains two defense in depth mitigations to help prevent exploitation of the ATL vulnerabilities described in Security Advisory 973882 and MS09-035 (the IE updates contains additional security fixes that are not related to the ATL issue).

    Was the msvidctl vulnerability (MS09-032) related to this ATL update?

    First of all, the kill bits issued by the July release for msvidctl (MS09-032) will block the public exploits of msvidctl as stated here.

    This public exploit took advantage of the fact that msvidctl uses a modified version of vulnerable ATL headers which is not in the public version. The vulnerabilities exploited in this attack are found in the private versions of ATL, as described in Security Advisory 973882. In this specific instance, the vulnerability allows an attacker to corrupt memory which may lead to a remote code execution. For more information on this specific issue see Michael Howard’s “Bug 1” in his SDL Blog Post.

    Will the IE update that helps protect against the ATL issues also protect against msvidctl attacks?

    Even without the kill-bits from MS09-032, the IE mitigations in MS09-034 will help protect against the exploitation of all the ATL vulnerabilities that are described and fixed in the Visual Studio bulletin. That said, we highly encourage you to not remove MS09-032 and keep your machine fully updated.

    - Fermin J. Serna, MSRC Engineering

    *Posting is provided "AS IS" with no warranties, and confers no rights.*

  • MS09-033: The Virtual PC vulnerability is not a VM breakout issue

    MS09-033 fixed a vulnerability in Virtual PC and Virtual Server which involves elevation of privilege. I’d like to use this blog post to clarify what the security impact is of this vulnerability, to help you make an informed decision about how you prioritize the installation of this update. To be clear, we highly recommend that you install the update, but recognize that you may need to prioritize the work of deploying the update against other important work.

    Which configurations are at risk?

    First of all, if you are using hardware-assisted virtualization this vulnerability does not affect Virtual PC 2007 or Virtual Server 2005. Windows XP compatibility mode in Windows 7 is also not affected. Any installation not using hardware-assisted virtualization is affected. Note that Virtual PC 2004 does not support hardware-assisted virtualization, so it is affected.

    What could an attacker do because of this vulnerability?

    This vulnerability does not allow an attacker to compromise a host operating system. The vulnerability could allow an attacker who can already run low privileged native code on the guest operating system to execute instructions that are supposed to be reserved for code running in ring 0. This would have no affect on the host operating system. The attacker could, however, achieve code execution within the guest operating system with system privileges, completely compromising the guest operating system.

    What are the attack vectors?

    It’s also important to note that the attacker must be able to run arbitrary native code on the guest operating system already. There are two main scenarios to consider that would allow this. The first is systems that allow users to log in and run native code programs at low privileges by design. The second is when an attacker convinces a non-malicious user of the system to run the malicious program, possibly through email or a malicious web site.

    How can I protect myself?

    Install the update from here: MS09-033

    We hope that having this additional information about how this vulnerability could be exploited will help you make a more informed decision about how urgently to apply this update.

    - Kevin Brown, MSRC Engineering

    *Posting is provided "AS IS" with no warranties, and confers no rights.*

  • MS09-031: More information about the ISA issue

    The ISA blog has a really great post this morning about MS09-031.  It only affects a specific configuration and they outline it.  If you have any questions about MS09-031, check out their blog.

    - Jonathan Ness, MSRC Engineering

    *Posting is provided "AS IS" with no warranties, and confers no rights.*

  • MS09-029: Vulnerabilities in the EOT parsing engine

    Today we released MS09-029, which addresses vulnerabilities related to EOT font files. To answer a few commonly asked questions, here is a brief FAQ regarding the update:

    Q: What is the EOT file format?
    A: EOT stands for Embedded OpenType Font. EOT support in Microsoft applications has existed for many years. It allows the fonts used in the creation of a document to travel with that document, ensuring that a user sees documents exactly as the designer intended them. Font embedding technology also exists on the web, allowing web pages to embed their own fonts.

    Q: What is the risk?
    A: Two commonly used applications which consume EOT files are Internet Explorer and Microsoft Office. A snippet of html used to render a specific font in Internet Explorer would look something like this:


    @font-face { font-family: "zhfont"; src: url(foo.eot) }


    It possible to navigate to a web site and have it render HTML, which then attempts to load a malicious font file. As a result, there is a “browse and get owned” attack scenario and we recommend updating your system as soon as you can.

    Q: How effective are the different workaround options listed in the bulletin?
    A: The different workaround options listed in the bulletin are all effective, though ACL'ing t2embed.dll is perhaps the best cross-product method workaround because it will prevent unidentified applications from loading t2embed.dll as well. Do remember that if you choose to ACL the binary as a workaround, you will need to un-ACL it before applying security update or update will fail.

    Q: If I ACL t2embed.dll, will IE/Office still work?
    A: Yes. If you browse to a site which tries to install a font, you will be able to view the site though you will not render the font provided by that site.

    Q: Is the EOT functionality reachable through 3rd party code?
    A: Yes. The t2embed library provides EOT functionality that can be used by 3rd party code. Many 3rd parties import t2embed for their font rendering, though some may chose to implement their own font rendering.

    - Brian Cavenah, MSRC Engineering

    *Posting is provided "AS IS" with no warranties, and confers no rights.*

  • More information about the Office Web Components ActiveX vulnerability

    We are aware of public attacks on the Internet exploiting a vulnerability in the Office Web Components Spreadsheet ActiveX control (OWC 10 and OWC11). Microsoft has released an advisory with further information available here.

    What’s the attacking vector?

    This vulnerability could be used for remote code execution in a "browse and get owned" scenario. User interaction is required since a user needs to go to a malicious website that hosts the exploit.

    What configurations are at risk?

    Neither OWC10 nor OWC11 are installed by default on any Windows version. However, it can be installed along several products:

    OWC10 OWC11
    Office XP Yes
    Office 2003 Yes Yes
    Office 2007
    ISA Server
    Office Accounting and Business Contact Manager
    Manually installed from Microsoft Download Center
    Yes Yes

    Yes=Installed by default (Vulnerable)
    Opt = Optional install (May be vulnerable)

    Please note, there are several scenarios and configurations that mitigate this vulnerability:

    • Outlook and Outlook Express are not affected because both open HTML mails in a zone where ActiveX is restricted. However, if a user follows a link to a malicious website, attackers could exploit this vulnerability.
    • ActiveX controls will not load in the Internet Zone on Windows Server 2003 or Windows Server 2008 if a user uses default settings when browsing, due to the Enhanced Security Configuration (ESC).
    • If OWC is not installed on the computer and the user visits a page hosting the attack then Internet Explorer 7 or 8 will show the gold bar prompt requesting permission to install the ActiveX.

    How do I check whether I am at risk?

    You can check whether a workstation is vulnerable to this attack by using the Classid.cs tool we published in a previous blog post.

    By default, if the control is installed, it can be instantiated and scripted as seen by the tool output below:

    C:\>ClassId.exe {0002E541-0000-0000-C000-000000000046} (*)
    Clsid: {0002E541-0000-0000-C000-000000000046}
    Progid: OWC10.Spreadsheet.10
    Binary Path: C:\PROGRA~1\COMMON~1\MICROS~1\WEBCOM~1\10\OWC10.DLL
    Implements IObjectSafety: True
    Safe For Initialization (IObjectSafety): True --- IE will allow loading
    Safe For Scripting (IObjectSafety): True --- IE will allow scripting
    Safe For Initialization (Registry): False
    Safe For Scripting (Registry): False
    KillBitted: False --- It is not killbitted

    (*) This example uses the OWC10 classid. Same applies to the OWC11 classid: {0002E559-0000-0000-C000-000000000046}

    How could I protect myself?

    In order to protect your system you can issue the killbit for the two classids by adding the following value in the registry following these steps:

    1) Use Registry Editor to view the data value of the Compatibility Flags DWORD in the following two registry keys:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{0002E541-0000-0000-C000-000000000046}

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{0002E559-0000-0000-C000-000000000046}

    2) Change or add the value of the Compatibility Flags DWORD value to 0x00000400.

    After applying the killbit you can check it again with the ClassId.cs tool:

    C:\>ClassId.exe {0002E541-0000-0000-C000-000000000046} (*)

    Clsid: {0002E541-0000-0000-C000-000000000046}
    Progid: OWC10.Spreadsheet.10
    Binary Path: C:\PROGRA~1\COMMON~1\MICROS~1\WEBCOM~1\10\OWC10.DLL
    Implements IObjectSafety: True
    Safe For Initialization (IObjectSafety): True
    Safe For Scripting (IObjectSafety): True
    Safe For Initialization (Registry): False
    Safe For Scripting (Registry): False
    KillBitted: True --- Since the kilbit has been applied, IE will refuse to load the control

    (*) This example uses the OWC10 classid. Same applies to the OWC11 classid: {0002E559-0000-0000-C000-000000000046}

    At this point you are no longer vulnerable to this threat through the IE vector.

    As mentioned in the advisory, we are also providing a way to apply this workaround automatically. You can click the button below to set the kill-bit on this control.

    Click Here To Kill-Bit OWC.Spreadsheet

    Please visit Microsoft Knowledge Base Article 973472 for more information about this FixIt option.

    - Fermin J. Serna, MSRC Engineering

    *Posting is provided "AS IS" with no warranties, and confers no rights.*

  • New vulnerability in MPEG2TuneRequest ActiveX Control Object in msvidctl.dll

    We are aware of active attacks exploiting a remote code execution vulnerability in Microsoft’s MPEG2TuneRequest ActiveX Control Object. We have released advisory 972890 providing guidance to help our customers stay protected. In this blog post, we’d like to go into more detail to help you understand this issue.

    What’s the attack vector? (i.e. How could a user be compromised?)

    A browse-and-get-owned attack vector exists. A user needs to be lured to navigate to a malicious website or a compromised legitimate website to be affected. No further user interaction is needed.

    By default, Outlook Express and Outlook open HTML e-mail messages in the Restricted sites zone. The Restricted sites zone helps reduce attacks that could try to exploit this vulnerability by preventing ActiveX controls from being used when reading HTML e-mail messages.

    However, if a user clicks a link in an e-mail message, they could still be vulnerable to this issue through the Web-based attack scenario.

    Which configurations are at risk?

    As indicated in the advisory, Windows XP and Windows Server 2003 are affected. Please note while Window Server 2003 is listed as affected platform, Enhanced Security Configuration (ESC) in Windows Server 2003 can effectively mitigate the attack via IE from the Internet Zone.

    How can I protect myself?

    Kill-bit MPEG2TuneRequest ActiveX Control Object (CLSID 0955AC62-BF2E-4CBA-A2B9-A63F772D46CF) is the workaround we recommend to mitigate the current attack in the wild.

    Why we recommend to kill-bit several other ActiveX Control Objects in msvidctl.dll as well?

    During the investigation, we identified that none of the ActiveX Control Objects hosted by msvidctl.dll are meant to be used in IE. Therefore, we recommend to kill-bit all of these controls as a defense-in-depth practice, as stated in Advisory 972890. The side effect is minimal.

    As mentioned in the advisory, we are also providing a way to apply this workaround automatically. You can click the button below to set the kill-bit on this control.

    Click Here To Kill-Bit MSVidCtl

    Please visit Microsoft Knowledge Base Article 972890 for more information.

    Chengyun Chu, MSRC Engineering