ASP.NET security update is live!

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?
  • Signature progress from protection partners
  • Updated snort rules
  • Thanks to the ASP.NET team for holiday heroics

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 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,; reference:url,; 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,; reference:url,; 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.

– Jonathan Ness, MSRC Engineering