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:
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.
(Internet Explorer)
(C Runtime [msvcrt.dll])
(.NET, Silverlight)
CVE-2012-0014 does not affect any ASP.NET scenario running at Medium Trust or Lower.
(Kernel Mode Drivers)
(AFD.sys)
The other vulnerability is exploitable for local elevation of privilege on 64-bit platforms only.
(Visio Viewer)
(SharePoint)
(Indeo)
(ColorUI)
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.
This month we released MS12-004 to address CVE-2012-0003 and CVE-2012-0004.
CVE-2012-0003
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 [-HKEY_CLASSES_ROOT\CLSID\{D51BD5A2-7548-11CF-A520-0080C77EF58A}]
CVE-2012-0004
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.
Summary
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
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: http://go.microsoft.com/?linkid=9776900.
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
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.
MS12-004
(Windows Media)
Windows 7 not affected by default by either of the two vulnerabilities.
See this SRD blog post for more information.
(Office)
(CSRSS)
(Object Packager)
(SSL / TLS)
(Anti-XSS Library)
(Kernel)
Today we released MS11-100, addressing a newly disclosed denial-of-service vulnerability affecting several vendors’ Web application platforms, including Microsoft’s ASP.NET. Yesterday, we posted an SRD blog describing the vulnerability and the detection and workaround opportunities. With this blog post, we’d like to update you on the following topics:
Why is this bulletin rated “Critical” for a Denial-of-Service vulnerability?
Yesterday evening, we published an Advanced Notification alerting customers to a new out-of-band security update planned to be released today. The notification listed the update as addressing a Critical Elevation-of-Privilege vulnerability, leading to several questions from customers who expected the bulletin addressing a Denial-of-Service vulnerability to be rated Important.
Before hearing about this vulnerability, we had planned to release a .NET security update addressing three vulnerabilities, one of which was a Critical elevation-of-privilege vulnerability. When this vulnerability notification arrived a few weeks ago, the ASP.NET team included the fix into the update already being developed and tested. So the bulletin today addresses four vulnerabilities, one of which is the ASP.NET Denial-of-Service vulnerability presented yesterday. You can read more about the other vulnerabilities in the Security Bulletin and we also invite you to join us for a webcast at 1:00 p.m. PST today (Dec 29) where we will describe the vulnerabilities and answer your questions live “on the air.” You can sign up for the webcast here.
Signature progress from protection partners
We have been working with our MAPP partners, answering questions and providing additional guidance. We are seeing early progress toward signatures, one of which being our own MMPC team having released a signature for the Forefront Threat Management gateway (TMG). The MMPC signature page is at http://www.microsoft.com/security/portal/Threat/Encyclopedia/NIS.aspx?threat=Vulnerability-Win-ASPNET-POST-DoS-CVE-2011-3414. We have also heard from partners about the progress they are making and are looking forwarding to seeing additional signatures this week. It’s exciting to see this information sharing mechanism working!
As we mentioned earlier, Web application servers from several vendors are affected by this same vulnerability. The “nice” thing about these kind of industry-wide issues is that our detection logic sent out to the MAPP partners results in protection for not just the Microsoft issue but for attacks targeting any affected platform.
Updated Snort rules
Sourcefire, while developing their IDS/IPS signature, has been kind enough to share their Snort rule with us and has given us permission both to use it in protecting Microsoft’s properties and also to share with customers. While the Snort rules we provided in the blog yesterday were effective in detecting the issue, Sourcefire's rules are more efficient. The first signature from yesterday would operate very rapidly, but the second – which had no static content match – would enter on every single TCP packet passing through the IDS. While it would exit rapidly in most cases due to the flowbit, the overhead from that would stack up and if the PCRE runs into a form post that sends 20+ parameters, the PCRE would start crunching away on the CPU quite rapidly. Thanks, Sourcefire team, for your help!
To that extent, here are two updated Snort rules:
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"DOS generic web server hashing collision attack"; flow:established,to_server; content:"Content-Type|3A| application|2F|x-www-form-urlencoded"; nocase; http_header; pcre:"/([^=]+=[^&]*&){500}/OP"; reference:cve,2011-3414; reference:url,events.ccc.de/congress/2011/Fahrplan/events/4680.en.html; reference:url,technet.microsoft.com/en-us/security/advisory/2659883; classtype:attempted-dos; sid:20823; rev:1;)
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"DOS generic web server hashing collision attack"; flow:established,to_server; content:"Content-Type|3A| multipart/form-data"; nocase; http_header; pcre:"/(\r\nContent-Disposition\x3a\s+form-data\x3b[^\r\n]+\r\n\r\n.+?){500}/OPsmi"; reference:cve,2011-3414; reference:url,events.ccc.de/congress/2011/Fahrplan/events/4680.en.html; reference:url,technet.microsoft.com/en-us/security/advisory/2659883; classtype:attempted-dos; sid:20824; rev:1;)
This first rule covers the x-www-form-urlencoded use case in a single rule, instead of using flowbits, because the stream reassembler and http_inspect will put the entire request together, and allows you to view it as a single logical packet. That eliminates the concern about a rule without a content match, and means that it should be reasonably fast. Also, this changes the number of parameters necessary to trigger an alert down to 500, because a) that should have virtually no false positives in the wild anyway, and b) the fewer parameters the PCRE needs to count out, the faster the rule will be. The second rule covers the multipart/form-data use case.
Additional acknowledgement
The ASP.NET team has worked straight through the past several weeks to make this short turnaround release possible – building, packaging, and testing this security update in order to release packages in such a short time so we could protect customers as quickly as possible.
Yesterday’s SRD blog mentioned a few of the team members but missed several others. With apologies to the team members who didn’t get mentioned and at the risk of forgetting others, here are the key ASP.NET engineers who made this compressed schedule possible: Anand Paranjape, Pranav Rastogi, Jim Wang, Clay Compton, Matt Fei, Hong Li, Carl Dacosta, Amit Apple, Drago Draganov, Konst Khurin, Levi Broderick, Miguel Lacouture-Amaya, Jason Pang, Jim Carley, Jon Cole, Mike Harder, Zhenlan Wang, Dmitry Robsman, Jeffrey Cooperstein, Nazim Lala, Qing Ye, Reid Borsuk, Jamshed Damkewala, Christy Henriksson, Jose Reyes, William Mitchell, Darla Hershberger, Sophy Wang, and Ashutosh Kumar. Thanks, all of you and others behind the scenes for your work to get this package out in such a short time!
Dec 29 update: Updated Snort rule with more efficient pcre from Sourcefire team. Previously "/([\w\x25]+=[\w\x25]*&){500}/OPsmi". Now "/([^=]+=[^&]*&){500}/OP". Should be ~10x faster. Thanks Caleb Jaren from the Microsoft Network Security Analysis & Monitoring team for testing it.
Today, we released Security Advisory 2659883 alerting customers to a newly disclosed denial-of-service vulnerability affecting several vendors’ web application platforms, including Microsoft’s ASP.NET. This blog post will cover the following:
Impact of the vulnerability
This vulnerability could allow an anonymous attacker to efficiently consume all CPU resources on a web server, or even on a cluster of web servers. For ASP.NET in particular, a single specially crafted ~100kb HTTP request can consume 100% of one CPU core for between 90 – 110 seconds. An attacker could potentially repeatedly issue such requests, causing performance to degrade significantly enough to cause a denial of service condition for even multi-core servers or clusters of servers.
We anticipate the imminent public release of exploit code. Therefore, we encourage ASP.NET website owners to review the Security Advisory 2659883 and this blog post to evaluate the denial-of-service risk to your web property and to implement the workaround and/or attack detection mechanisms until a security update is available to comprehensively address the issue.
Vulnerable configurations
The root cause of the vulnerability is a computationally expensive hash table insertion mechanism triggered by an HTTP request containing thousands and thousands of form values. Therefore, any ASP.NET website that accepts requests having HTTP content types application/x-www-form-urlencoded or multipart/form-data are likely to be vulnerable. This includes the default configuration of IIS when ASP.NET is enabled and also the majority of real-world ASP.NET websites.
Detecting attacks at the network layer
Microsoft has released detailed detection guidance and code to test signatures to all 80 of our MAPP partners. We expect that the network-based IDS and IPS vendors in the program will build robust detection and protection signatures for this issue. Microsoft’s own Forefront Threat Management Gateway (TMG) will receive an update containing a signature for this issue today. (Vulnerability:Win/ASPNET.POST.DoS!NIS-2011-0001)
Microsoft’s internal network security analysis & monitoring team has developed a snort signature to detect attacks on the wire. They are currently testing it and plan to put it into production to protect Microsoft’s own network. There are two rules:
alert tcp any any -> any $HTTP_PORTS (msg:"Microsoft 2659883 URL Encoded Content flowbit"; flow:established,to_server; content:" application|2F|x|2D|www|2D|form|2D|urlencoded";nocase;http_header;flowbits:set,urlEncodedContentType;flowbits:noalert;classtype:misc-activity; sid:1000019; rev:1;)
alert tcp any any -> any $HTTP_PORTS (msg:"Confirmed Microsoft 2659883 payload";flow:established,to_server;flowbits:isset,urlEncodedContentType;pcre:"/(\w*(&|=)){1000,}/smi";flowbits:unset,urlEncodedContentType; sid:1000020;rev:1;)
The first rule will check for the content type “application/x-www-form-urlencoded”. If it is present, the rule will set the flowbit “urlEncodedType”. If the urlEncodedType flowbit is set, the second rule will check for 1000 or more form values being sent in the HTTP request. As Microsoft, the other affected vendors, and protection partners continue to investigate this issue, we will likely discover more efficient ways to detect exploits in the wild. Please contact us at switech –at- microsoft dot com with ideas for more efficient detection than the above.
Detecting attacks at the server level
Successful attacks will exhaust server CPU resources. Therefore, you can detect attacks by something as simple as Task Manager on the web server. The screenshot below shows the result of one malicious request against a 4 core machine. Notice that one entire core is dedicated to processing this one request (~25% CPU usage).
More information about the workaround to protect your web properties
The security advisory lists workaround steps to limit the maximum HTTP request size that ASP.NET will accept from clients. Attackers would need to send (relatively) large HTTP requests to exploit the vulnerability. So if your website does not normally need to accept large requests from legitimate users, you can configure ASP.NET to reject all requests larger than a certain size. Note that if your website does need to accept user uploads, this workaround is likely to block legitimate requests. In that case, you should not use this workaround and instead wait for the comprehensive security update.
If your application uses ViewState, we recommend limiting HTTP request size to 200kb. To do so, add the following to your ASP.NET configuration file:
<configuration> <system.web> <httpRuntime maxRequestLength="200"/> </system.web></configuration>
If your application does not use ASP.NET ViewState, we recommend limiting HTTP request size to 20kb. To do so, add the following to your ASP.NET configuration file:
<configuration> <system.web> <httpRuntime maxRequestLength="20"/> </system.web></configuration>
Note that any requests larger than the maxRequestLength will result in a ConfigurationErrorsException thrown server-side and an HTTP error status returned to the client. Therefore, we want to stress that this workaround option will disrupt both legitimate and attack HTTP requests that exceed the request length. Therefore, please thoroughly test this workaround in your environment, focusing on any scenarios that involve uploading files or making large data submissions to the web service.
Non-workaround – URLScan
Microsoft’s URLScan tool often helps mitigate vulnerabilities involving malicious HTTP requests. However, it is not applicable in this particular case because the malicious form values in a successful attack are most likely to be in the body of the HTTP request, not in the URL itself. URLScan does not inspect the request body. Attacks are unlikely to be successful using only the URL (even factoring in cookies, headers, server variables, etc) due to a default 16KB limit for the combined request size excluding the request body. The request body is the only unbounded payload.
Conclusion
Our ASP.NET team is hard at work testing a security update for broad deployment. If you are concerned about the risk of your ASP.NET site being targeted by attackers, please consider implementing the detection and workaround guidance described in this blog post.
Thanks to the ASP.NET team for the hours and hours of work spent over the holiday on this issue - Dmitry Robsman, Jeffrey Cooperstein, Zhenlan Wang, Matt Fei, Nazim Lala, Jamshed Damkewala, Hong Li, Reid Borsuk and others! Thanks Mike Harder for your work investigating different workaround options. Thanks Dave Midturi, David Seidman, Andrew Gross, and Maarten van Horenbeeck for your help in coordination. Thanks Chengyun Chu and Ali Pezeshk for your technical investigation. And finally thanks Caleb Jaren and Abhijeet Hatekar for the snort signature help!
- Suha Can and Jonathan Ness, MSRC Engineering
Today we released thirteen security bulletins. Three have a maximum severity rating of Critical with the other ten 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.
Browser-based attack vector more difficult to both trigger and exploit than the Office document attack vector. Successful exploitation results in code running as SYSTEM.
See this SRD blog post for more information about attack vectors and workarounds.
IE7 and later have disabled this particular binary behavior already.
See this SRD blog post for more information about this binary behavior and why we are disabling it via a killbit security update.
Thanks to the entire MSRC Engineering team for the hard work on these cases!!
This month we released MS11-090 to address a vulnerability in the Microsoft Time component (CVE-2011-3397), which features the deprecated time behavior that is still supported in IE6. We would like to provide further information about this issue and help explain why a “binary behavior kill bit” is the appropriate course of action.
Which products are affected?
The vulnerable component was removed from IE7 and later browsers. IE6 is the only supported browser that is affected.
What is, or was, the time behavior?
The time behavior is a feature of HTML+TIME 1.0, which was released in IE5. It provides an active timeline for enabling animated content.
Why is CVE-2011-3397 included in the ActiveX Kill Bits bulletin (MS11-090) instead of in the cumulative IE bulletin (MS11-099)?
The most appropriate remedy for this issue is to issue a kill bit to disable the deprecated binary behavior.
What is the binary behavior kill bit?
Usually, the kill bits we issue are targeted toward disabling specific ActiveX Objects. For example, the following registry key sets a kill bit for an ActiveX object on x86-based systems:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}] "Compatibility Flags"=dword:00000400
The binary behavior kill bit is very similar. To set a kill bit for a particular binary behavior, you can use:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}] "Compatibility Flags"=dword:04000400
The highlighted bit notifies IE to never load binary behaviors from the specific CLSID. The registry key for x64-based systems is:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control
x86 IE:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control
For more information about the kill bit, please refer to David Ross’s excellent Kill-Bit FAQ Series. It will be updated shortly to discuss the binary behavior kill bit.
Special thanks to Kwan-Leung Chan and Eric Lawrence on the IE team.