[NT] Unchecked Buffer in ASP.NET Worker Process

From: support@securiteam.com
Date: 06/08/02

From: support@securiteam.com
To: list@securiteam.com
Date: Sat,  8 Jun 2002 21:38:19 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Unchecked Buffer in ASP.NET Worker Process


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


Affected Software:
 * Microsoft .NET Framework version 1.0, of which ASP.NET is a component.

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.

Patch availability:
Download locations for this patch
 * Microsoft .NET Framework version 1.0

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 Session State?
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 us 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 are 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 Session State by providing a way for web servers to correlate
individual page requests from a single user into a more meaningful overall

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 has recognized that sensitive personal
information should never be stored in cookies.

How do Cookies Enable Session State?
HTTP is a stateless protocol, meaning there is 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 have chosen. When
you then go to a checkout page, it can read the cookie to see what items
you have purchased. It can then generate a single page for items selected
on multiple pages.

How is Session State 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

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.NET Manage Session State?
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
 * 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 that 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

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 constructing an
especially 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

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


The information has been provided by
<mailto:0_32255_E51E4D7D-DECD-43AE-9A29-36080E8D4C3C_US@Newsletters.Microsoft.com> Microsoft Product Security.


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com


The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.