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.
- Chengyun Chu, 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!!
- Jonathan Ness, MSRC Engineering
Today, we released MS11-087 addressing an issue in the font parsing subsystem of win32k.sys, CVE-2011-3402. The bulletin received a Critical rating due to a potential browser-based attack vector. We have not seen the browser-based attack vector exploited in the wild. The bulletin includes a workaround to disable this remote code execution attack surface. You might consider applying the workaround even after applying security update MS11-087, simply to reduce your attack surface. This blog explains how in more detail.
Issue Summary
This vulnerability has been used to drop the Duqu malware. An insufficient bounds check within the font parsing subsystem of win32k.sys could potentially allow a malformed font to corrupt ring0 memory. In the case of the Duqu dropper, a malformed font embedded inside an Office Word document triggered this memory corruption vulnerability to jump to attacker shellcode.
To be clear, Duqu did not exploit the browser-based attack vector. As far as we know, this vulnerability has only been exploited via a custom font embedded within an Office document. However, attackers could potentially construct a malicious font in such a way that it could be embedded in a webpage. There is an easy workaround to block that particular attack surface.
Protecting your environment
The best option for protecting against this particular vulnerability is to apply the MS11-087 security update. It will comprehensively address this issue.
If you are unable to apply the update right away and/or are concerned primarily about the browser-based attack surface, you might consider simply disabling IE’s ability to download custom fonts entirely. The side effect of this approach is potential display and layout glitches on web pages that leverage custom fonts to display text in interesting new ways. However, the vast majority of web sites use fonts included with Windows or use text layout tricks that do not require this particular custom font technology. Opening a web page that embeds a custom font after you have applied the workaround will cause Internet Explorer to display the text using a built-in font. Below, you can see the user experience of browsing to a webpage that leverages a custom font:
Figure 1: Webpage using custom, downloaded font
Figure 2: Same webpage displayed after workaround is applied
Workaround Steps
You can disable custom font download in Internet Explorer either interactively (using the GUI) or via Group Policy or a Management Deployment Script across multiple machines.
- Interactive deployment
- Group Policy deployment
NOTE: The Group Policy MMC snap-in can be used to set policy for a machine, for an organizational unit or an entire domain. It is assumed that the reader will know how to deploy the steps below for their particular environment.
- Managed Deployment Script deployment
This security setting can be manually entered into the registry by creating a registry script and importing it either by double clicking it or running regedit.exe as part of a logon or machine startup script. For managed deployments Regedit.exe can be used to import a registry script silently with the ‘-s’ switch. For more information on regedit command line switches refer to: http://support.microsoft.com/kb/q82821/
To set this setting to ‘Prompt’ for the Internet and Local Intranet Zones paste the following text into a .REG file and then import the .REG file on managed machines as part of your organizations managed deployment process:
Windows Registry Editor Version 5.00 ; Zone 1 is the local intranet zone ; 1604 is the Font download policy ; dword:00000001 sets the policy to prompt [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1] "1604"=dword:00000001 ; Zone 3 is the internet zone [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3] "1604"=dword:00000001
To set this setting to ‘Disable’ for the Internet and Local Intranet Zones paste the following text into a .REG file and then import the .REG file on managed machines as part of your organizations managed deployment process:
Windows Registry Editor Version 5.00 ; Zone 1 is the local intranet zone ; 1604 is the Font download policy ; dword:00000003 sets the policy to disable [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1] "1604"=dword:00000003 ; Zone 3 is the internet zone [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3] "1604"=dword:00000003
Bottom Line
We encourage you to first apply the security update to address this particular vulnerability. However, you might consider also blocking the browser-based font attack surface from within Internet Explorer as a good ‘attack surface reduction’ step. The tiny minority of web pages that embed custom fonts may display differently but you will be protected from any potential browser-based attack vectors leveraging custom fonts within Internet Explorer.
- Chengyun Chu and Jonathan Ness, MSRC Engineering
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 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.