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

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

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.

- Jonathan Ness, MSRC Engineering