Security Research & Defense

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

February, 2012

  • Assessing risk for the February 2012 security updates

    Today we released nine security bulletins. Four have a maximum severity rating of Critical with the other five 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 Likely first 30 days impact Platform mitigations and key notes
    MS12-010

    (Internet Explorer)

    Victim browses to a malicious website. Critical 1 Likely to see exploit code developed in next 30 days.  
    MS12-013

    (C Runtime [msvcrt.dll])

    Victim browses to a malicious website or opens a malicious media file. Critical 1 Likely to see exploit code developed in next 30 days. See this blog post for more information about the attack surface.
    MS12-016

    (.NET, Silverlight)

    Victim browses to a malicious website with a Silverlight-enabled browser. Critical 1 Likely to see exploit code developed in next 30 days. CVE-2012-0015, the publicly disclosed vulnerability, does not affect Silverlight or the latest version of the .NET Framework.

    CVE-2012-0014 does not affect any ASP.NET scenario running at Medium Trust or Lower.

    MS12-008

    (Kernel Mode Drivers)

    Attacker logs-in locally to a machine and exploits the vulnerability to elevate to a higher privilege level. Critical 1 Likely to see exploit code developed in next 30 days for local elevation of privilege. The only Critical-class vulnerability addressed in this bulletin is much more difficult to exploit. It has a “2” Exploitability Index Rating.
    MS12-009

    (AFD.sys)

    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 for local elevation of privilege. One of the two vulnerabilities affects only Windows Server 2003.

    The other vulnerability is exploitable for local elevation of privilege on 64-bit platforms only.

    MS12-015

    (Visio Viewer)

    Victim opens a malicious Visio document (VSD) in Visio Viewer. Important 1 Likely to see an exploit developed in next 30 days. Visio itself is not affected, only the Viewer.
    MS12-011

    (SharePoint)

    Attacker sends victim a link exploiting a Cross-Site Scripting (XSS) vulnerability on a SharePoint server for which they have access rights. When the victim clicks the link, an automatic action is taken on their behalf on the SharePoint server that they otherwise might not have wanted to execute. Important 1 Likely to see a XSS exploit developed in next 30 days (no exploit here for code execution on the SharePoint server itself). The IE XSS Filter (on by default on IE8 and IE9) blocks attempts to exploit these vulnerabilities.
    MS12-014

    (Indeo)

    Victim browses to a malicious WebDAV share and launches an application by double-clicking a content file hosted on the attacker-controlled WebDAV share. Important 1 Likely to see an exploit developed in next 30 days. You can read more background on this DLL Preloading vulnerability and the fix method on this SRD blog post.
    MS12-012

    (ColorUI)

    Victim browses to a malicious WebDAV share and launches an application by double-clicking a content file hosted on the attacker-controlled WebDAV share. Important 1 Likely to see an exploit developed in next 30 days. Does not affect client SKU’s (XP, Windows 7, etc).

    Only affects Windows Server 2008 and Windows Server 2008 R2 because the DLL was removed. However, DLL Preloading vulnerabilities like this one are less likely to be exploited on server platforms due to the extensive user interaction required.

    - Jonathan Ness, MSRC Engineering

  • MS12-014: Indeo, a blast from the past

    Today, we shipped security update MS12-014 to address an issue in the Indeo codec. With this blog post, we hope to preemptively answer some common questions that are likely to surface as researchers analyze this security update.

    Indeo: Blast from the Past

    Indeo is a video codec that was first developed in 1992, long before some of you reading this blog post were born. :) In the days before MPEG – and more than a decade before youtube – Indeo was one of the first video codecs allowing full-speed video playback without using hardware acceleration.

    However, today Indeo is an obsolete technology. In fact, Windows Vista and all later versions of Windows shipped with the codec disabled by default. In 2009, we took a further step of attack surface reduction for older versions of Windows by releasing a security advisory and shipping an update to block Indeo from being launched in Internet Explorer or Windows Media Player. That update, shipped via Automatic Updates, removed the most common remote attack vectors for this code while still allowing games or other legacy applications to leverage the codec locally and continue to function.

    MS12-014: Why and How

    Windows now blocks the remote video playback functionality of Indeo but the codec itself and its infrastructure remain on the system for legacy application support. Unfortunately, a DLL Preloading issue has been identified leveraging Indeo. In the following set of circumstance, an attacker could run arbitrary code on a system:

    • If an attacker lures a victim into browsing to a network share or WebDAV share where attacker has write access, AND
    • If the attacker lures victim into double-clicking a content filetype that is handled by or registered to Indeo, AND
    • If the attacker has placed a specifically-named malicious DLL on the share,
    • Then Indeo will inadvertently load the malicious DLL while attempting to open the content file on which the victim double-clicked.

    Due to the particular challenges in servicing Indeo, we took an unusual approach this time. This security update drops a “dummy DLL” on the system having the filename that the attacker’s malicious DLL would need to have to exploit the vulnerability. This effectively removes the vulnerability because the DLL will be found already on the system and Indeo will not attempt to load a malicious DLL from the attacker-controlled share.

    Hope that helps answer questions you might have about this security update.

    Thanks to Josh Carlson, MSRC Ops for the help with this one. (and congrats on shipping your first bulletin)

    - Jonathan Ness, MSRC Engineering

  • MS12-013: More information about the msvcrt.dll issue

    Today we are shipping a security update to address a Critical-class memory corruption vulnerability in the Microsoft C Run-Time Library (msvcrt.dll) shipped with Windows. We have issued the bulletin with Critical severity because attackers could potentially trigger the vulnerability by luring a victim into browsing to a malicious webpage that launches Windows Media Player, or by opening a malicious file with Windows Media Player.

    Seldom-used functionality

    While the Windows Media Player attack vector is unfortunate, one might look at the affected DLL (msvcrt.dll), recognize that a number of Microsoft applications load the DLL, and speculate that a large percentage of applications might be vulnerable. Thankfully, that is not the case. Based on what we have seen in our code base, the affected functions are rarely used by components shipping with Windows. At this time, Media Player is the only known vector to provide an exploit path for the vulnerability. And even if other attack vectors are discovered, after applying the security update, all Microsoft products will be protected from the issue.

    Applications built with recent versions of Visual Studio are safe by default

    All applications built with Visual Studio 2003 and higher are not affected by this issue, unless they are specifically loading msvcrt.dll. Starting from Visual Studio 2003, any program that is dynamically linked to the C Run-Time library will use msvcrXX.dll instead of msvcrt.dll.

    It is important to note that msvcrt.dll is a known DLL. This means that it is a system component owned and built by Windows. It is intended for future use only by system-level components. An application should use and redistribute msvcrXX.dll. Windows will only look in %WINDIR%\system32 to locate msvcrt.dll. Any application that is linked to msvcrt.dll will load the vulnerable version, regardless of the presence of another version in the current directory – though, again, applying this bulletin eliminates the issue.

    Guidance for 3rd party application developers

    If you have developed an application by statically linking to the C Run-Time library shipped with Visual Studio, you are safe. If your program is dynamically linked to the C Run-Time library, then you should ensure that all your objects are linked with a recent version of Visual Studio. This will assure that you are using msvcrtXX.dll and are not affected by this problem.

    - Ali Rahbar, MSRC Engineering