ASP.NET Security Update Shipping Thursday, Dec 29th

A few minutes ago Microsoft released an advance notification security bulletin announcing that we are releasing an out-of-band security update to address an ASP.NET Security Vulnerability.

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.

  • The event registration link yields "You are unable to view this event as you do not have sufficient permissions."

  • Thanks for the timely response to this. We're already making plans for workarounds anyway.

  • @Dustin,

    >>>>>>> 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.

    Hope this helps,

    Scott

  • @Rafael,

    >>>>>> The event registration link yields "You are unable to view this event as you do not have sufficient permissions."

    The link should become active shortly.

    Hope this helps,

    Scott

  • Hi Scott,

    Well done to you and the team for coming up with a fix so quickly!

    Will this fix limit the number of Request parameters, limit the number of items in a collided bucket, or some other fix? Is there a chance that existing functionality could break?

    Thanks!

    Kirk

  • 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

  • Microsoft were notified of this issue in November. Wasn't it possible for Microsoft to notify customers >1 day ahead of the update becoming available?

  • From the bulletin:

    "Sites that disallow application/x-www-form-urlencoded or multipart/form-data HTTP content types are not vulnerable"

    Can you explain this part in more detail? How would I determine if my sites fall in that category?

  • is there a shipping time / announcement with a download link coming?

  • Gr8... i have registered for webcast and really very excited for it..

  • Regarding my previous comment, it has been answered over here: http://forums.asp.net/t/1754148.aspx/1?ASP+NET+Denial+of+Service+Vulnerability+2659883

  • It seems like there are many solutions to prevent hash-table attacks. I wonder what solution was chosen for ASP.NET?

  • Scott,

    Regarding Azure -- I'm glad this is a transparent and automatic update. Yet another reason I love hosting with Azure.

    Pete

  • The TechNet webcast is up on this. Search for "EventID: 1032502799 webcast"

  • The workaround to restrict http post size... I'm guessing the default (4Mb?) is too much?

  • What is the new limit on Request.Form fields, and is it configurable on the server?

    Ever since installing this update I'm seeing a lot of "System.Web.HttpException (0x80004005): The URL-encoded form data is not valid." errors being generated from pages with 1000+ fields...

    I'm tempted to try uninstalling this update, but would rather find a better solution.

  • Pedro/PSmo,

    >>>>> 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.

    Hope this helps,

    Scott

  • 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) . . .





  • Thanks! the appSetting: is perfect!

  • @scott you didn't answer Stilgar comment, who asked about JSON deserialization to dynamic objects. Isn't this a vulnerability point, too?

    It seems to me that it may well be, and that the fix you've provided (max 1000 parameters) is not going to help in that case.

    Or maybe this is already taken care of by ASP.NET?

  • @Sam,

    >>>>>> 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.

    Hope this helps,

    Scott

  • @stilgar, @bystander

    >>>>> One of the changes we made with this security update was to also add protection to JSON input and deserialization - so those should be protected too.

    Hope this helps,

    Scott

  • 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.

  • Does this apply to Classic ASP as well?

  • 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?

  • Thanks to Sam and PSmo. The key works perfectly.
    Hours and hours spent on a senseless bug thanks to MS not publishing the consequences of an update! No official documentation at all!

  • Thank for your helping me solve the problem on the server.

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

    What is the real fix to this security issue? Creating a hash table that can handle 100000 of items shouldn't be a problem!

    /mattias

  • 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.

    OMG I love Gu. ;/

  • 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?





  • Kinda alarming, good thing you guys are on it. Scott, thanks for the update- gotta check the forums too.

  • @Alun Jones,

    >>>>>> 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.

    Hope this helps,

    Scott

  • @Andrew,

    >>>>>> Does this apply to Classic ASP as well?

    Classic ASP uses a different hashtable implementation and has a limit on the request size which mitigates the same type of attacks.

    Hope this helps,

    Scott

  • @RichardD,

    >>>>>> 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.

    Hope this helps,

    Scott

  • @la,

    >>>>>> I tried the fix and it did not work for me. Any other suggestions?

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

    Thanks,

    Scott

  • @ToddB,

    >>>>>>>> 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.

    Thanks,

    Scott

  • @mattiasw,

    >>>>>> 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).

    Hope this helps,

    Scott

  • @Joshua,

    >>>>>>> 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.

    Hope this helps,

    Scott

  • @Ansh,

    >>>> 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.

    Thanks,

    Scott

  • 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.

    Thanks again to the great ASP.NET team at Microsoft.

    Chris

  • 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?

  • @ToddB,

    Looks like MS11-100 enforces the same (1000) limit for JSON payloads, which is controlled by yet another appSetting:






  • 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.

    In that case it adds
    Pragma: no-cache
    Cache-control: no-cache
    Expires: -1

    This is not a header that shows up anywhere in IIS!

    And, it also added X-Powered-By: ASP.NET to all the websites, even though I had explicitly removed that header sometime ago.

    Thought you should know...

  • I have used below setting in my web config but its not working









  • Hash collision attacks try to fill a hash-table within a computer app with immense lottery of items whose keys calculate to the identical hash encipher.

  • Hi Scott, do shared hosting users need to worry about that or it will be updated automatically?

  • Can this security fix have an impact on pages with large viewstate? We are seeing the exception on pages posting back only 11 discrete form values, however they do have an abnormally large viewstate.

  • 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?

  • Hi Scott,

    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.

  • Hi All

    I had the same issue - but I have changed the web.config in the view dir. and not in the root. after the root was updated it worked.










  • 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?

  • @Fidel,

    >>>>>> 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.

    Thanks,

    Scott

  • @JimG,

    >>>>> 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.

    Send me email (scottgu@microsoft.com) if you are still seeing issues.

    Hope this helps,

    Scott

  • @M Noreen

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

    Thanks,

    Scott

  • @M Noreen

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

    Thanks,

    Scott

  • @JF,

    >>>>> 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.

    Thanks,

    Scott

  • @James,

    >>>>> 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.

    Thanks,

    Scott

  • @Andy,

    >>>>> 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.

    Thanks,

    Scott

  • As far as I know, six new appSettings switches were added:

    aspnet:MaxHttpCollectionKeys (documented)
    aspnet:UseLegacyFormsAuthenticationTicketCompatibility (documented)
    aspnet:UseLegacyEncryption (undocumented)
    aspnet:AllowRelaxedRelativeUrl (undocumented)
    aspnet:RestrictXmlControls (undocumented)
    aspnet:AllowRelaxedHttpUserName (undocumented)

    Where can I find complete documentation about these switches?

  • 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.

    Reducing the maximum number isn't engineering, it's problem avoidance!!

  • 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.
    "

    More info here: http://support.microsoft.com/kb/2638420

  • 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?

  • :)

  • Hi Scott,

    Well done to you and the team.

  • .net 1.1 regedit DWORD:MaxHttpCollectionKeys can not work
    help!

    win2008 64 .net 1.1 KB2656353

  • Cool Stuff Scott! You always rock!

  • So 1000 form fields is below any type of DoS threashold.

    What it too large a value?

    Is 3000 form fields "safe"?

  • 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.

    Any help would be appreciated.

  • Hi Scott,

    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.

    Thanks in advance.

    Regards,
    Sandy

  • Thanks for This Vital Information.

  • Thanks for This Vital Information.

  • Scott,

    We discovered a missing SP on our tet system. Once we applied 2008 Server Sp2, then applied the .net patches for each .net version, we resolved both of our issues.

    # re: ASP.NET Security Update Shipping Thursday, Dec 29th
    Monday, January 16, 2012 12:40 AM by ScottGu
    @JimG,

    >>>>> 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.

    Send me email (scottgu@microsoft.com) if you are still seeing issues.

    Hope this helps,

    Scott




  • Good afternoon Mr. Scott!

    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?

Comments have been disabled for this content.