Question

Microsoft recently (12-29-2011) released an update to address several serious security vulnerabilities in the .NET Framework. One of the fixes introduced by MS11-100 temporarily mitigates a potential DoS attack involving hash table collisions. It appears this fix breaks pages that contain a lot of POST data. In our case, on pages that have very large checkbox lists. Why would this be the case?

Some non-official sources seem to indicate that MS11-100 places a limit of 500 on postback items. I can’t find a Microsoft source that confirms this. I know that View State and other framework features eat up some of this limit. Is there any configuration setting that controls this new limit? We could switch away from using checkboxes but it works rather well for our particular situation. We’d also like to apply the patch because it protects against some other nasty things.

Unofficial source discussing the 500 limit:

The bulletin fixes the DOS attack vector by providing a limit to the
number of variables that can be submitted for a single HTTP POST
request. The default limit is 500 which should be enough for normal
web applications, but still low enough to neutralize the attack as
described by the security researchers in Germany.

EDIT: Source code with example of limit (which appears to be 1,000, not 500)
Create a standard MVC app and add the following code to the main index view:

@using (Html.BeginForm()) 
{
    <fieldset class="fields">
        <p class="submit">
            <input type="submit" value="Submit" />
        </p>

        @for (var i = 0; i < 1000; i++)
        {
            <div> @Html.CheckBox("cb" + i.ToString(), true) </div>
        } 
    </fieldset>
}

This code worked before the patch. It doesn’t work after. The error is:

[InvalidOperationException: Operation is not valid due to the current
state of the object.]
System.Web.HttpValueCollection.ThrowIfMaxHttpCollectionKeysExceeded()
+82 System.Web.HttpValueCollection.FillFromEncodedBytes(Byte[] bytes, Encoding encoding) +111
System.Web.HttpRequest.FillInFormCollection() +307

Answer 1

Try adding this setting in web.config. I just tested this on .NET 4.0 with an ASP.NET MVC 2 project and with this setting your code doesn’t throw:

<appSettings>
  <add key="aspnet:MaxHttpCollectionKeys" value="1001" />
</appSettings>

That should work now (after you have applied the security update) to change the limit.

---

I hadn’t updated my machine yet, so using Reflector I checked the HttpValueCollection class, and it didn’t have the ThrowIfMaxHttpCollectionKeysExceeded method:

I installed KB2656351 (update for .NET 4.0), reloaded the assemblies in Reflector and the method appeared:

So that method is definitely new. I used the Disassemble option in Reflector, and from what I can tell from the code it checks an AppSetting:

if (this.Count >= AppSettings.MaxHttpCollectionKeys)
{
  throw new InvalidOperationException();
}

If it doesn’t find the value in the web.config file, it will set it to 1000 in System.Web.Util.AppSettings.EnsureSettingsLoaded (an internal static class):

 _maxHttpCollectionKeys = 0x3e8;

---

Also, Alexey Gusarov tweeted about this setting two days ago:

• http://twitter.com/#!/tr_tr_mitya/status/152473667102715904
• http://twitter.com/#!/tr_tr_mitya/status/152475158941138944

And here is an official answer from a Q&A with Jonathan Ness (Security Development Manager, MSRC) and Pete Voss (Sr. Response Communications Manager, Trustworthy Computing):

Q: Is AppSettings.MaxHttpCollectionKeys the new parameter that
contains the maximum number of form entries?

A: Yes it is.