MS09-036: ASP.NET Denial-of-Service vulnerability

We have released MS09-036 to address an anonymous denial of service (DoS) vulnerability in ASP.NET. We’d like to go into more detail in this blog to help you understand:

• Which configurations are at risk?
• What could happen if my configuration is impacted?
• How can I protect myself?

Which configurations are at risk?

This vulnerability can only be triggered using ASP.NET on webservers running IIS 7 in integrated mode. So all the following configurations are not affected:

• IIS6 server are safe;
• IIS7 with application pools only in classic mode is safe;
• IIS7 on Windows Vista SP2 or Windows Server 2008 SP2 is safe.

Windows 2000, Windows XP and Windows Server 2003 are not affected by this issue since IIS7 can only be installed in Windows Vista and Window Server 2008.

Specifically, we would like to clarify the following questions:

Question 1: Is the vulnerability in IIS7, or in ASP.net?

This is an issue in ASP.net, which is shipped as part of .NET Framework.

Question 2: How could I know whether the version of .NET Framework installed in my Windows Vista/Windows 2008 machine contains vulnerable code or not?

For Windows Vista, and Windows Server 2008, let’s take a look for the supported .NET Framework’s installation scenario. Also, note that Windows Server 2008 RTM shipped with Service Pack 1 of OS (see http://technet.microsoft.com/en-us/library/dd335038.asp for more information)

For all the supported scenarios above, only .NET Framework 2.0/3.0 SP2 shipped with Windows Vista SP2/Windows Server 2008 SP2 are not affected. That’s why we said previously that IIS7 on Windows Vista SP2 or Windows Server 2008 SP2 is safe.

Question 3: I am confused. It is said that the vulnerability is in .NET Framework. How could the .NET Framework 2.0/3.0 SP2 on Windows Vista SP1 is affected while the .NET Framework 2.0/3.0 SP2 on Windows Vista SP2 is NOT affected?

Due to the incremental build environment, the in-box .NET 2.0/3.0 SP2 version shipped with Windows Vista SP2 and Windows Server SP2 is not affected by this vulnerability. To clarify, even the version number (2.0/3.0 SP2) is kept the same, the in-box .NET 2.0/3.0 SP2 version shipped with Windows Vista SP2 and Windows Server SP2 has already included the fix of this vulnerability.

Question 4: What about .NET Framework 3.5?

.NET Framework 3.5 is built incrementally upon .NET Framework 2.0 and 3.0. In this context, .NET Framework 3.5 is equivalent to .NET Framework 2.0/3.0 SP1, and .NET Framework 3.5 SP1 is equivalent to.NET Framework 2.0/3.0 SP2. So if you have .NET Framework 3.5 SP1 installed on Vista RTM, SP1 or Windows Server 2008 RTM/SP1, you also have an affected version of .NET Framework 2.0 SP2 installed.

What could happen if my configuration is impacted?

The attack is a remote anonymous DoS attack to ASP.NET. In other words ASP.NET would stop processing requests. Therefore:

• This is not a DoS against the underlying OS operating system (i.e. Windows).
• This is not a DoS against IIS7. IIS7 is still running, which means if you have a webpage which does not require ASP.NET, the webpage would not be affected. Only web pages requiring ASP.NET functionality would be affected.

How could I recover from the attack?

Restarting IIS’s application pool will recover your application from the attack. You could do it via command-line utility iisreset.exe or IIS UI.

UI: In the IIS Manager tool go to the “Application Pools” node. In the right-hand pane choose the application pool to recycle. Right click on the desired application pool and select “Recycle” from the pop-out menu. These steps are illustrated below.

Mitigation and Workarounds?

As indicated, IIS7 on Windows Vista SP2 or Windows Server 2008 SP2 are not affected. Therefore, you may consider upgrading your system to Windows Vista SP2 or Windows Server 2008 SP2. However there are potential compatibility issues developers should be aware of when upgrading ASP.NET applications to the version of the .NET Framework that is included in Windows Vista SP2 and Windows Server 2008 SP2. For a current list of known issues see http://forums.asp.net/t/1305800.aspx.

Other options would be changing how IIS processes the requests for managed code. The workarounds listed in the security bulletin are examples of this approach.

In IIS 7.0, application pools run in one of two modes: integrated mode and classic mode. The application pool mode affects how the Web server processes requests for managed code. If a managed application runs in an application pool with integrated mode, the Web server uses the integrated, request-processing pipelines of IIS and ASP.NET to process the request. However, if a managed application runs in an application pool with classic mode, the Web server continues to route requests for managed code through Aspnet_isapi.dll, processing requests the same as if you were running in IIS 6.0.

For reference, here are a number of links that discuss ISAPI (i.e. classic mode) and integrated mode:

• Classic mode request processing: http://msdn.microsoft.com/en-us/library/ms178473.aspx
• Integrated mode request processing: http://msdn.microsoft.com/en-us/library/bb470252.aspx
• A list of breaking changes when trying to move a classic mode application to integrated mode: http://learn.iis.net/page.aspx/381/aspnet-20-breaking-changes-on-iis-70/
• An overview article that talks about some ASP.NET functionality that can be extended to non-ASP.NET content: http://learn.iis.net/page.aspx/243/aspnet-integration-with-iis7/

As indicated in the bulletin, a viable workaround is to either configure the MaxConcurrentRequestsPerCPU registry key or maxConcurrentRequestsPerCPU attribute in the aspnet.config to shift request from the CLR threadpool (which is what ASP.NET is interacting with) to the IIS native threadpool.

Update 8/17/2009: Bulletin number and hyperlink corrected.

- Chengyun Chu, MSRC Engineering

*Posting is provided “AS IS” with no warranties, and confers no rights.*