Security Research & Defense

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

January, 2012

  • More information on MS12-004

    This month we released MS12-004 to address CVE-2012-0003 and CVE-2012-0004.


    The most severe of these vulnerabilities is CVE-2012-0003 which is a Critical, Remote Code Execution vulnerability. This CVE affects all editions of Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008. Windows 7 is not affected by this vulnerability.

    An effective workaround for CVE-2012-0003 is to disable Directshow’s MIDI parsing. Apply the following registry file would unregister the MIDI parser in Directshow.

    Windows Registry Editor Version 5.00


    CVE-2012-0004 is an Important-class vulnerability also involving Windows Media Player. The vulnerability in the closed caption decoding component (L21 decoder) is contained within DirectShow. Therefore, the multimedia applications that leverage DirectShow to decode closed caption streams might be affected.

    As a mitigation, the latest WMP player, WMP12, has closed caption turned off by default. As shown in the below picture, the setting to display close caption content is disabled. Therefore, WMP12 users are not affected by this vulnerability by default.


    MS12-004 is our top-priority bulletin for January 2012; though the mitigation described above is effective and we have seen no exploitation attempts against either of the CVEs covered, we recommend that customers apply the bulletin as soon as possible.

    Special thanks to Jeremy Tinder in MSRC and Ali Rahbar in MSRC Engineering.

    - Chengyun Chu, MSRC Engineering

  • More information on the impact of MS12-001

    Today we released MS12-001, which addresses an issue that can enable an attacker to bypass a defense in depth feature known as SafeSEH. This bypass is limited in scope to applications that make use of binaries that were built with Microsoft Visual C++ .NET 2003 RTM. Binaries that have been built with Microsoft Visual C++ .NET 2003 Service Pack 1 and beyond are not affected. In this blog post we wanted to provide more details on the issue that has been addressed and what impact it has. In addition, we’ll clarify the parameters of the “Security Feature Bypass” vulnerability category assigned to this bulletin.

    What is SafeSEH?

    SafeSEH is a defense–in-depth security feature that is designed to make it more difficult for attackers to exploit certain types of vulnerabilities. In particular, SafeSEH is designed to prevent attackers from using an attack technique known as an “SEH overwrite”. More details on how this is accomplished can be found in a report we released in July of last year:

    Microsoft released support for SafeSEH in Visual Studio 2003 RTM. Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1 were the first versions of Windows to be built with SafeSEH enabled.

    What issue is being addressed?

    This issue can result in SafeSEH not being enforced for a binary that has been built with support for SafeSEH. This occurs when a binary that was built with Microsoft Visual C++ .NET 2003 RTM is loaded by an application running on a version of Windows that is affected by MS12-001.

    The reason that SafeSEH is not enforced in this scenario is because Microsoft Visual C++ .NET 2003 RTM produces binaries with metadata that is a different size than what the Windows loader expects. As a result, the loader conservatively falls back to assuming that the binary does not support SafeSEH. MS12-001 addresses this issue by allowing binaries to have metadata of the size that is produced by Microsoft Visual C++ .NET 2003 RTM.

    What impact does this issue have?

    Failing to enforce SafeSEH for a binary can enable an attacker to more easily develop an exploit for a vulnerability. The attacker must have found a vulnerability that can enable code execution for this to be possible; the issue addressed by MS12-001 does not enable code execution in and of itself. Furthermore, it does not enable elevation of privilege, information disclosure, or the like. For this reason, we’ve assigned MS12-001 to the very small category of “Security Feature Bypass” vulnerabilities. Though failure to enforce SafeSEH is by no means desirable, the issue in itself does not constitute an exploit vector.

    Although the set of binaries affected by this issue is limited, some of the affected binaries are extensively used by applications. For example, the redistributable C runtime DLLs (such as msvcrt.dll) from Visual Studio 2003 are affected by this issue. These DLLs also do not enable support for ASLR and are therefore an attractive target for use in developing an exploit. EMET can be used to better mitigate these concerns by enabling mandatory ASLR and SEHOP for applications that make use of such DLLs.

    Do I need to rebuild my binaries if they were built with Visual C++ 2003?

    Installing the update for MS12-001 will fully address this issue without requiring any binaries to be rebuilt. Alternatively, this issue can also be resolved by rebuilding affected binaries with Microsoft Visual C++ .NET 2003 Service Pack 1 or later. You can determine if your binary is affected by this issue by using the Microsoft Visual C++ linker command “link.exe /dump /headers binary.dll”. Binaries with a Load Config Directory size of 0x48 are affected as shown below.

    File Type: DLL
                7.10 linker version
              100000 size of heap reserve
                1000 size of heap commit
                   0 loader flags
                  10 number of directories
               3AC74 [    43E0] RVA [size] of Export Directory
               49298 [      28] RVA [size] of Import Directory
               52000 [     3B8] RVA [size] of Resource Directory
                   0 [       0] RVA [size] of Exception Directory
                   0 [       0] RVA [size] of Certificates Directory
               53000 [    2B64] RVA [size] of Base Relocation Directory
               39B48 [      38] RVA [size] of Debug Directory
                   0 [       0] RVA [size] of Architecture Directory
                   0 [       0] RVA [size] of Global Pointer Directory
                   0 [       0] RVA [size] of Thread Storage Directory
               49078 [      48] RVA [size] of Load Configuration Directory

    Thanks to Gerardo Di Giacomo and our colleagues in Windows Sustained Engineering for their work on addressing this issue.

    Matt Miller, MSEC Security Science

  • Assessing risk for the January 2012 security updates

    Today we released seven security bulletins. One has a maximum severity rating of Critical with the other six having a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

    Bulletin Most likely attack vector Max Bulletin Severity Max Exploit-ability rating Likely first 30 days impact Platform mitigations and key notes


    (Windows Media)

    Victim browses to a malicious website or opens a malicious media file. Critical 1 Likely to see exploit code developed in next 30 days.

    Windows 7 not affected by default by either of the two vulnerabilities.

    See this SRD blog post for more information.



    Victim opens a malicious PPS or DOC file. Important 1 Likely to see exploit code developed in next 30 days.


    Attacker logs-in locally to a machine and exploits the vulnerability to elevate to a higher privilege level. Important 1 Likely to see exploit code developed in next 30 days. Only affects systems with double-byte consoles. (English locale not affected.)

    Windows Vista and later platforms not affected.

    (Object Packager)

    Victim browses to a malicious WebDAV or SMB share and opens a Publisher (PUB) file. Publisher executes a potentially malicious executable hosted on the same WebDAV or SMB share. Important 1 Likely to see exploit code developed in next 30 days.

    (SSL / TLS)

    Victim browses to a trusted website via HTTPS. A malicious attacker positioned on the network as a man-in-the-middle actively attacks the session by injecting content into the stream to exploit this vulnerability and a second vulnerability (to bypass the browser’s same origin policy) resulting in content from the HTTPS session being leaked to the attacker. Important 3 Exploit code for information disclosure is already available. However, this vulnerability cannot be leveraged for code execution. See this SRD blog post for more background on the vulnerability.

    (Anti-XSS Library)

    Web application expecting the anti-XSS library to sanitize content by removing script might inadvertently consume a string containing script. Important 3 This vulnerability cannot be leveraged for code execution.


    If an attacker is able to (separately) discover a code execution vulnerability in an application developed using Visual C++ 2003 RTM, it may be less difficult than it otherwise would be to subsequently develop an exploit due to SafeSEH not being enforced. Important 3 This vulnerability cannot be leveraged for code execution. See this SRD blog post for more background on the vulnerability.

    - Jonathan Ness, MSRC Engineering