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.
(C Runtime [msvcrt.dll])
CVE-2012-0014 does not affect any ASP.NET scenario running at Medium Trust or Lower.
(Kernel Mode Drivers)
The other vulnerability is exploitable for local elevation of privilege on 64-bit platforms only.
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
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:
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)
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.
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