Microsoft Security Bulletin MS02-026

Technical description:

ASP.NET is a collection of technologies that help developers to build web-based applications. Web-based applications, including those built using ASP.NET, rely on HTTP to provide connectivity. One characteristic of HTTP as a protocol is that it is stateless, meaning that each page request from a user to a site is reckoned an independent request. To compensate for this, ASP.NET provides for session state management through a variety of modes.

One of these modes is StateServer mode. This mode stores session state information in a separate, running process. That process can run on the same machine or a different machine from the ASP.NET application. There is an unchecked buffer in one of the routines that handles the processing of cookies in StateServer mode. A security vulnerability results because it is possible for an attacker to seek to exploit it by mounting a buffer overrun attack. A successful attack could cause the ASP.NET application to restart. As a result, all current users of the web-based application would see their current session restart and their current session information would be lost.

The StateServer mode is not the default mode for session state management in ASP.NET. ASP.NET applications using StateServer mode that do not use cookies are not vulnerable.

Mitigating factors:

• StateServer mode is not the default mode for session state management in ASP.NET. That ASP.NET application would have to be specifically configured to use this mode.
• Even if an application was configured to use StateServer mode, it would only be at risk if it also used cookies.

Severity Rating:

The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them. The vulnerability is only exposed through the use of StateServer mode in conjunction with cookies. StateServer mode is not the default session state mode for session state management.

Vulnerability identifier: CAN-2002-0369

Tested Versions:

Microsoft tested .NET Framework 1.0 to assess whether they are affected by this vulnerability. There are no pervious versions of .NET Framework.

What's the scope of the vulnerability?
This is a buffer overrun vulnerability. An attacker who was able to successfully exploit this vulnerability could cause the application running on the web server to restart. In addition, while Microsoft has not been able to demonstrate it, there is the possibility that an attacker could exploit this vulnerability to cause code to run on the web server. The code could run in the security context of the ASP.NET worker process, which uses an unprivileged account by default.
The vulnerability only affects ASP.NET applications that use StateServer mode to manage session state information. This is not the default mode. Finally, only those applications using StateServer mode that also use cookies are affected. Applications that use StateServer mode without cookies are not affected by the vulnerability.

What causes the vulnerability?
The vulnerability results because a function that processes cookie data in the ASPState service fails to properly check the length of the cookies passed to it.

What is ASP.NET?
ASP.NET is collection of technologies within the .NET Framework that lets developers build web applications and XML Web Services.
Unlike traditional web pages, which use a combination of static HTML and scripting, ASP.NET uses compiled, event-driven pages. This allows developers to build web-based applications with the same richness and functionality usually associated with applications built in languages such as Visual Basic or Visual C++. Unlike desktop applications, however, these complied pages generate information that is sent to client desktops or browsers using markup languages such as HTML and XML. This lets developers build applications with the broad functionality, yet project user interface to devices and systems running many operating systems.
Because ASP.NET is a web-based application environment, it requires an underlying web server to provide it basic HTTP functionality. For this reason, ASP.NET runs on top of IIS 5.0 on Windows 2000 and IIS 5.1 on Windows XP. The problem in this particular case involves how ASP.NET handles an aspect of HTTP functionality: session state.

What is SessionState?
ASP.NET applications are web-based applications. As such, they build on the same basic concepts as traditional web applications. One of the most important of these concepts is Session State.
By design, Hypertext Transfer Protocol, HTTP, is a stateless protocol. This means that from the perspective of the networking layer each interaction between a web server and a web browser is a separate, unrelated interaction. For example, suppose you look at a web page that lists all shoes in your size at an online shoe retailer. Let's say you then click on a particular shoe to bring up its specific page. From the standpoint of the web server, these two interactions are completely unrelated from each other: they're two wholly independent exchanges. There is no way for the web server to know that these requests are part of the same user session.
Since users interact with web sites rather than web pages, cookies were introduced to help overcome this limitation. Cookies introduce the concept of < a href="http://msdn2.microsoft.com/en-us/library/ms952598.aspx">Session State by providing a way for web servers to correlate individual page requests from a single user into a more meaningful overall session.

What are Cookies?
Cookies are data files that are stored on the user's local system. They are free form in structure and content: a web site can choose to store any information they choose in cookies. However, because the information always passes in clear text, it's recognized that sensitive personal information should never be stored in cookies.

How do CookiesEnableSessionState?
HTTP is a stateless protocol, meaning there's no way for a web server to be able to associate multiple page requests with a single session. Because cookies give web sites a way to store data on the client, they provide a way to overcome this limitation. Web sites can use cookies to store information that can be used to correlate multiple requests on the site to create a single overall session. In essence, one page can make a note in the cookie that can then be read by another page. This then effectively creates sessions.
For instance, if you choose to purchase a pair of shoes, the retailer's site could make a note in the cookie of the shoes you've chosen. When you then go to a checkout page, it can read the cookie to see what items you've purchased. It can then generate a single page for items selected on multiple pages.

How is SessionState Handled on the Server?
While it is cookies stored on the local computer that first made session state possible, state management is ultimately driven by the web server and not the client. The web server has to know what to do with the state information. In addition, different applications will have different requirements for using state information. Ultimately, this means that there will be differences in how this information is handled on the server.
To this end, ASP.NET introduces several different ways of managing session state to accommodate different requirements for applications.
For example, an online shoe retailing application that is hosted on a single server is going to have different requirements in managing session state than one hosted on a server farm.

How does ASP.NETManageSessionState?
In addition to relying completely on cookies to manage session state information, ASP.NET provides an option to allow some or all of the session state information to be managed on the server. This can improve performance by reducing the amount of information that must be exchange between the web server and the client.
ASP.NET provides three ways to manage session state information on the server:

• In-process mode.
• Out-of-process mode (also known as StateServer mode)
• SQL Server mode

In-Process mode stores the session state information in the same running program as the ASP.NET application itself. This has the benefit of speed, since the session information is immediately available to the application. The disadvantage of this is that it cannot be used on web farms, since the information is contained on a single machine. This is the default session state for ASP.NET applications.
StateServer mode stores the session state information in a separate running program, the ASPState service. This can run on the same system or a different system than the ASP.NET application. The advantage of this is mode is that it can support web farm scenarios.
SQL Server mode is similar to StateServer mode in that it supports web farm scenarios. In this case, session state information is stored on a database server, which can be accessed by any member of the application farm. Because of the scalability of SQL Server, this is the preferred option for managing session state information in web farm scenarios.

What's wrong with how the StateServer mode handles cookies?
There is an unchecked buffer in one of the functions in the StateServer mode function that handles the processing of cookies when they are presented to ASP.NET.

How is that possible? I thought unchecked buffers are impossible in the .NET Framework?
While the StateServer itself is written using the .NET Framework, there are some helper functions which it calls that are not written using the .NET Framework. The flaw which gives rise to the vulnerability is located in one of these helper functions written using traditional code.
It is planned, however, to migrate all functions over to the .NET Framework. That work is currently underway now. Because this is an architectural change and not the type of change that can safely be made in a security patch the results of this work will be made in the first available large scale ship vehicle.

So this vulnerability doesn't affect .NET Framework managed code at all?
Correct. The vulnerability has nothing to do with .NET Framework's managed code.

What could this vulnerability enable an attacker to do?
An attacker could seek to exploit this vulnerability and mount a buffer overrun attack. A successful attack could cause the ASP.NET application to restart.
In addition, while Microsoft has not been able to reproduce the execution of code in our testing, we think it nonetheless remains possible that an attacker could exploit this vulnerability and cause code to execute. However, the ASP.NET worker process runs by default in a non-privileged security context. As a result, an attacker's code would run with very limited abilities on the system if they were able to introduce code of their choice via this vulnerability.

How could an attacker exploit this vulnerability?
An attacker could seek to exploit this vulnerability by crafting a specially malformed cookie and presenting that cookie to the ASP.NET application. When the cookie was processed by the ASP.NET application and the buffer overrun, the ASP.NET application would restart.

You said that only applications using StateServer in conjunction with cookies could be vulnerable, can you give more detail?
Because the flaw the causes the vulnerability is in a function related to the handling of cookies in StateServer mode, any ASP.NET application that uses StateServer mode but does not use cookies does not expose the vulnerability.

What does the patch do?
The patch eliminates the vulnerability by implementing proper checks on cookies that are processed in StateServer mode.

I'm using StateServer mode, but not using cookies, should I apply the patch?
Yes. If you are going to use StateServer mode, even without cookies, you should apply the patch to ensure that the vulnerability is address should you decide to use cookies at any point. However, you should also consider using SQL Server mode instead.

Download locations for this patch

• Microsoft .NET Framework version 1.0

  http://www.microsoft.com/downloads/details.aspx?FamilyId=633DFFD9-C083-4FF5-8D7D-1474CAC0239B&displaylang=en