Dec 29th Update: the security update (MS11-100) has now shipped and is available to install via Windows Update, the Windows Server Update Service and as a download from the Microsoft Download Center.

The security update we are releasing resolves a publicly disclosed Denial of Service issue present in all versions of ASP.NET. We’re currently unaware of any attacks on ASP.NET customers using this exploit, but we strongly encourage customers to deploy the update as soon as possible.

We are releasing the security update via Windows Update and the Windows Server Update Service. You can also manually download and install it via the Microsoft Download Center. We will release the update on Thursday, December 29th at approximately 10am Pacific Time (US and Canada). We are announcing it ahead of time to ensure that administrators know that the security update is coming, and are prepared to apply it once it is available.

More about the Security Vulnerability

On Dec 28th 2011, details were published at a security conference describing a new method to exploit hash-table data-structures used in web frameworks. Attacks targeting this type of vulnerability are generically known as “hash collision attacks”.

Hash collision attacks attempt to populate a hash-table within a server app with large numbers of items whose keys resolve to the same hash code. These key collisions can significantly slow down operations on the hash-table, and with enough elements can cause a server to spend minutes (or even hours) processing them. This can block a web server from processing requests from other users, and cause a denial of service (meaning the web site becomes unresponsive or slow).

Attacks such as these are not specific to any particular language or operating system. Presenters at the security conference discussed how to cause them using standard HTTP form posts against several different web frameworks (including ASP.NET). Because these attacks on web frameworks can create Denial of Service issues with relatively few HTTP requests, there is a high likelihood of attacks happening using this approach. We strongly encourage customers to deploy the update as soon as possible.

The security update we are releasing on Thursday, December 29th updates ASP.NET so that attackers can no longer perform these attacks. The security update does not require any code or application changes.

Learn More

You can learn more about this security vulnerability from the Microsoft Security Advisory (2659883) we have already released. We will release the security update on Windows Update, the Windows Server Update Service and the Microsoft Download Center on Thursday Dec 29th at approximately 10:00am Pacific Time (US and Canada).

Dec 29th Update: the security update (MS11-100) has now shipped and is available to install via Windows Update, the Windows Server Update Service and as a download from the Microsoft Download Center.

If you have questions about the vulnerability or have any issues applying the update, you can post questions in the Security Vulnerability forum on the www.asp.net web-site.

For all the latest information, you can also follow the MSRC team on Twitter at @MSFTSecResponse.

Hope this helps,

Scott

75 Comments

Hi Scott,

How does this affect Azure customers? We have several applications running in Azure instances, mostly in ASP.NET MVC3 and .NET 4.0.

>>>>>>> How does this affect Azure customers? We have several applications running in Azure instances, mostly in ASP.NET MVC3 and .NET 4.0.

Customers on Azure that have their Hosted Services OS servicing policy set to "Auto" (which is the default) will have their environments automatically updated to include the security update. There is no action required for this.

I am curious about how the fix work. Did you put some limit on request fields, did you build a special hashtable-like data structure that adds randomization to the hashcode or you tweaked the core .NET HashTable (or GetHashCode) to include randomization?

Also will your fix prevent this types of attacks when JSON data is sent over the wire. If you are deserializing JSON data into a strongly typed object I believe you are not vulnerable but if you are throwing JSON data into a hashtable (as it has been fashionable lately with the dynamic type) you might still be vulnerable

>>>>> The newly released security update which addresses imposes a limit of 1000 form parameters.

Correct - once the patch is applied it by default limits the number of individual form fields to be 1000 per HTTP post. This is well below any type of DoS threashold, and we felt was large enough for all but a few applications.

This limit is configurable, though, and so if you do have scenarios where you need to post more than 1000 fields you can increase it. You can do this by adding a setting into the section of the web.config file for your application and setting the value appropriately.

For example:

We've enabled this within so that you can set this in any application and not worry about it breaking on an un-patched server.

Scott, I'm wondering if /how we can set the value at the page level. Of the many forms on our site, only one is massive. It would be nice to do something like this in the web.config (similar to what we do for extending httpRuntime executionTimeout) . . .

>>>>>> Scott, I'm wondering if /how we can set the value at the page level. Of the many forms on our site, only one is massive. It would be nice to do something like this in the web.config (similar to what we do for extending httpRuntime executionTimeout) . . .

Unfortunately the setting can only be set at the application level with the security update that we shipped this week.

Other languages and frameworks have addressed this by adding some entropy (aka "randomness") to the hash start state, so as to allow large numbers of hash entries without the concommitant risk of malicious hash collisions. Are there plans to do this at some point in the future with ASP.NET and other platforms used / provided by Microsoft? It seems a little kludgey to pick a random number with a few zeroes at the end, and insist that no form (or JSON data) can have that many entries.

The security bulletin states:
"The majority of customers have automatic updating enabled ... this security update will be downloaded and installed automatically."

I checked four servers this morning, all of which have automatic updating enabled, and none of them had installed this update. WU had detected the update, but not selected it. I've now got to wait for a suitable time for a manual install.

Have I got a setting wrong somewhere, or was this a deliberate choice?

Once again you have the right info at the right time. I have an application that I'm demoing to a customer in 30 min that happens to have a form that because of the data I'm processing has over 1000 form fields. Thanks to you that demo will go smoothly... and I may refactor things later based on this update.

Hi the use of the below app config entries work just fine. But I have two web.config files, one global and one for particular application. If I make the change in global Web.config the problem gets resolved but if I make change in local (app specific) web.config then it seems its not able to override the settings. Any idea on why this might not work on local web.config?

>>>>>> Other languages and frameworks have addressed this by adding some entropy (aka "randomness") to the hash start state, so as to allow large numbers of hash entries without the concommitant risk of malicious hash collisions. Are there plans to do this at some point in the future with ASP.NET and other platforms used / provided by Microsoft? It seems a little kludgey to pick a random number with a few zeroes at the end, and insist that no form (or JSON data) can have that many entries.

We will likely add hashtable support for entropy/randomness as well in the future. Right now we are using the limit we set to block the primary vector of attack.

>>>>>> I checked four servers this morning, all of which have automatic updating enabled, and none of them had installed this update. WU had detected the update, but not selected it. I've now got to wait for a suitable time for a manual install. Have I got a setting wrong somewhere, or was this a deliberate choice?

Because Windows Update is used by hundreds of millions of machines we typically issue patches with the auto-update policy set to 0% and then slowly increase the % as we gain confidence that there are no issues with patch setup (so as to avoid a scenario where we impact hundreds of millions of machines with a bug we missed).

The patch showed up as being available immediatley for everyone when we issued it - so you can apply it immediately. If your policy is set to auto-update then it will apply automatically at some point even if you take no explicit action.

>>>>>>>> After this patch was applied to a Win2003 server, my asp.net app fails when performing an AJAX postback. Below is what shows up in the event viewer. I tried uninstalling the patch and using the aspnet:MaxHttpCollectionKeys setting with now success.

Send me email (scottgu@microsoft.com) if you are still having problems and I can help.

>>>>>> However, if the problem occurs above 1000 fields, what happens if I change to 5000. Is my site unsecure?

Do you have more than 1000 fields as top-level items on your page? In general we've found that pretty rare (especially for public internet sites). Note that you can have any level of nesting within your fields (meaning you can have infinitely nested JSON within each of the 1000 fields).

>>>>>>> We just applied the patch last night to a production server, and today we have been getting repeated issues where some pages of the site throw the following exception.

Once the patch is applied it by default limits the number of individual form fields to be 1000 per HTTP post. This is below any type of DoS threashold, and we felt was large enough for all but a few applications. It looks like your application might have a scenario where it is posting more than that number.

This limit is configurable, though, and so if you do have scenarios where you need to post more than 1000 fields you can increase it. You can do this by adding a setting into the section of the web.config file for your application and setting the value appropriately.

For example:

We've enabled this within so that you can set this in any application and not worry about it breaking on an un-patched server.

>>>> Hi the use of the below app config entries work just fine. But I have two web.config files, one global and one for particular application. If I make the change in global Web.config the problem gets resolved but if I make change in local (app specific) web.config then it seems its not able to override the settings. Any idea on why this might not work on local web.config?

Send me email (scottgu@microsoft.com) if you are still having problems and I can help.

Hi Scott,
I'm a little confused. You mention in the future you might introduce entropy to the hash table to mitigate such a hash-collision based attack. How does that work out of interest? Would it be server side and transparent to the client?

The corrective action is different for those applications on ASP.NET 1.1. This information comes (in)directly from Microsoft's team:

"On .NET 1.1 ASP.NET appsettings don’t apply and you need to use the registry to set this value.
HKLM\Software\Microsoft\ASP.NET\1.1.x.x\[DWORD:MaxHttpCollectionKeys] = 5000"

To re-state the solution:

1) Open RegEdit on the server hosting the application.
2) Navigate to the hive: HKEY_LOCAL_MACHINE\Software\Microsoft\ASP.NET\1.1.x.x\
3) Right-click the node and create a new DWORD.
4) Name the DWORD key MaxHttpCollectionKeys
5) Set the value by double-clicking on the new key and entering the desired maximum value (in the example above, this is 5,000). Be sure to select Decimal as the number format here before entering your value.
6) Re-start IIS. Open a command prompt and type "IISReset" and press enter.
7) Test the affected page or site again and verify that the issue is resolved.

This is really good information. But I want a few more:-
1. You just mentioned that Microsoft has enabled MaxHttpCollectionKeys in . What was the default value of MaxHttpCollectionKeys and Where this key was stored before this patch?
2. How we decide the values of this key in case of a form which is generated dynamically based on database table rows? Is there any maximum value?
3. Is it Vulnerable if we set the maximum value?

Scott - there appear to be a few "odd" behaviors that the security update has created. I have been able to verify and confirm this on 3 distinct servers (dev, test, and production).

First, it created a aspnet_client\system_web\4_0_30319 subdirectory under each and every site hosted in IIS (whether or not it was .net based...), and it appears to be an empty directory. No big deal, but obnoxious.

Second, and very weird ... it appears to have added custom reponse headers. But wait, there's more. The response headers are only added when I navigate to a certain page, and the best I can tell is that it happens to be the page defined by the "defaultURL" attribute in the authentication->forms section of web.config.

After applying this update we were seeing errors related to this security fix on pages which were posting back a small number of form values. These pages do have a large viewstate, does this security update also affect pages which have large viewstate?

Has anyone experienced any issues with sessionID cookies after installing this update. I'm seeing inconsistencies with Forms Authentication between FF, Chrome and IE. FF is the only one that's working.

Hey Scott, we're seeing the addition of the "no-cache="Set-Cookie"" Cache-Control header to the response after applying the patch. Unfortunately, that seems to cause issues when downloading files to an IE8 browser (specifically pdf). Using Fiddler, I can see the file does in fact come down, but IE just gives you a blank screen and won't open it when that header value is there. I've seen other posts about the issue, but no resolution. Any thoughts?

>>>>>> I'm a little confused. You mention in the future you might introduce entropy to the hash table to mitigate such a hash-collision based attack. How does that work out of interest? Would it be server side and transparent to the client?

Yes - this would be done server side and be transparent to the client.

>>>>> We've experienced 2 problems. One with kb2656353 (.net 1.1 fix) that is similar to support.microsoft.com/.../2433751 in where .net cross version authtication is broken after applying the patch. Once the patch was removed this was no longer an issue.

You need to make sure the patch is installed on all machines in the web farm as the forms auth ticket format has changed (to improve security with it - something that is included with the same update that addresses the hash table vulnerability). Once you install the patch on all machines you shouldn't have any problems.

>>>>> After applying this update we were seeing errors related to this security fix on pages which were posting back a small number of form values. These pages do have a large viewstate, does this security update also affect pages which have large viewstate?

You shouldn't see a problem with this - send me email (scottgu@microsoft.com) and we can help.

>>>>> Has anyone experienced any issues with sessionID cookies after installing this update. I'm seeing inconsistencies with Forms Authentication between FF, Chrome and IE. FF is the only one that's working.

I haven't heard of an issue like this. Send me email (scottgu@microsoft.com) and we can have someone help.

>>>>> Hey Scott, we're seeing the addition of the "no-cache="Set-Cookie"" Cache-Control header to the response after applying the patch. Unfortunately, that seems to cause issues when downloading files to an IE8 browser (specifically pdf). Using Fiddler, I can see the file does in fact come down, but IE just gives you a blank screen and won't open it when that header value is there. I've seen other posts about the issue, but no resolution. Any thoughts?

Can you send me email (scottgu@microsoft.com) about this? I can have someone help.

Hi Scott,
We had a our first report of a problem with this security fix this morning, but the appSetting fix is working.
However, due to a single page (in an authenticated area) that could easily have in excess of 5000 controls, we're having to put the value at a "dangerously" high level.
As Sam asked on the 31st Dec, do you have any plans to allow the configuration at a page level?
Many thanks,
Tom

This doesn't sound like a fix too me, it sounds like a quick workaround, avoiding fixing the exploit within the implementation of the underlying hashtable code.

Incidentally, I'm seeing quotes such as "not affecting many Internet websites" that may be true, but many of us use .NET to write private business applications that may have lots of form controls on one web page, having such an update slip in automatically over Christmas, potentially affecting business critical portions of a web app. isn't much fun if somebody needs to use the system urgently.

Make sure you install the updates on all servers in a cluster env. Installing it in just a few servers will cause random log outs (since the auth tickets will not work across patched and non patched boxes). "The security updates that are offered in security bulletin MS11-100 change the way that ASP.NET creates forms authentication tickets. The new behavior is incompatible with the previous behavior. Tickets that are generated by using the new behavior cannot be read by servers that use the old behavior, and vice versa. Therefore, because of the ticket behavior change, administrators whose applications use forms authentication must take specific steps when they deploy the security updates offered in bulletin MS11-100 to make sure that all servers switch to the new behavior concurrently.
"

Scott - We installed this patch on our test web servers. Immediately after our web sites stopped working. We were getting the "Operation is not valid due to the current state of the object" error. We tried backing out the patch without success. Since the web application uses Framework 1.1 we cannot use the fix to the web.config for 4.0.

Our production server does not have the patch and it is still working. My boss is afraid of a DoS and wants to apply the patch ASAP. What can we do to allow Framework 1.1 web apps with a couple thousand controls to continue working after the patch is applied?

We installed MS11-100 last week Monday COB and Tuesday morning we were getting several error types on the prod server.

One was fixed by using the appSetting:

The other is "System.Web.HttpException: This is an invalid webresource request."

System.Web.HttpException: This is an invalid webresource request.
at System.Web.Handlers.AssemblyResourceLoader.System.Web.IHttpHandler.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

This error is only occuring for some of the users; different controls are not being rendered correctly. User A may have the button missing and user B may have a titlebar missing.

We do know that all the dlls are present on the server as we did a compare between dev and prod server. We are alos assuming this has to do with the server patch as we did not have this error in our logs until the patch was applied.

Thanks so much for the info. I tried updating the we.config file with a value
I also tried 1000, 1001 and many other combinations, but I always get the same error: System.Web.HttpValueCollection.ThrowIfMaxHttpCollectionKeysExceeded() +2692302

This app is on .Net 2.0 and has a lot of Viewstate elements. Please advise what should be the criteria for the selection of MaxHttpCollectionKeys values. Was there any other option that I could try out here. Please advise.

>>>>> We've experienced 2 problems. One with kb2656353 (.net 1.1 fix) that is similar to support.microsoft.com/.../2433751 in where .net cross version authtication is broken after applying the patch. Once the patch was removed this was no longer an issue.

You need to make sure the patch is installed on all machines in the web farm as the forms auth ticket format has changed (to improve security with it - something that is included with the same update that addresses the hash table vulnerability). Once you install the patch on all machines you shouldn't have any problems.

I’m Cristina and I’m student of graduation in TIC (Information and Communication Technologies) of Universidade de Trás-os-Montes e Alto Douro (Portugal). Under a proposed work in the discipline of Programming Methodologies III, would like to participate in this forum to share experiences so we can all expand our knowledge. I can talk whit you about MVC and WFP?