TechNet Home >  Security >  Bulletins

   Microsoft Security Bulletin MS02-026
                                                                                                             [Print] Print

  Unchecked Buffer in ASP.NET Worker Process (Q322289)

  Originally posted: June 06, 2002

  Summary

       Who should read this bulletin: Customers operating web servers running ASP.NET applications.

       Impact of vulnerability: Denial of Service, Potentially Run Code of Attacker's Choice.

       Maximum Severity Rating: Moderate

       Recommendation: Customers using StateServer mode should apply the patch. Customers who do not use StateServer
       mode need not take any action.

       Affected Software:

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

  Technical details

       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:
                Internet Servers  Intranet Servers Client Systems

        ASP.NET Moderate          Moderate         None
       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.

  Frequently asked questions

       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'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://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnproasp/html/bringingstatetohttp.asp">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 Cookies Enable Session State?

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

  Patch availability

       Download locations for this patch

          * Microsoft .NET Framework version 1.0
            http://www.microsoft.com/Downloads/Release.asp?ReleaseID=39298

  Additional information about this patch

       Installation platforms:
       This patch can be installed on systems running the .NET Framework version 1.0 SP1

       Inclusion in future service packs:
       The fix for this issue will be included in .NET Framework Service Pack 2.

       Reboot needed: Yes

       Superseded patches: None.

       Verifying patch installation:

          * To verify that the patch has been installed on the machine, confirm that the following registry key has
            been created on the machine:
            HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.0\NDP10SP317396\M322289.

       Caveats:

          * Microsoft has learned users who are silently installing MS02-026 and have VS.NET open may experience system
            instability. When installing the hotfix for MS02-026, there is the possibility of the installation not
            being correctly completed if the affected files are locked during the installation of the hotfix. This can
            occur when the hotfix installation is run in silent mode and the files are locked or when the hotfix is run
            in a non-silent mode and the prompt to close the applications that are locking the files is disregarded.
            Microsoft encourages users not to install the patch while VS.NET is running. Please refer to Q324292 for
            more information.

       Localization:
       Localized versions of this patch are available at the locations discussed in "Obtaining other security patches".

       Obtaining other security patches:
       Patches for other security issues are available from the following locations:

          * Security patches are available from the Microsoft Download Center, and can be most easily found by doing a
            keyword search for "security_patch".
          * Patches for consumer platforms are available from the WindowsUpdate web site
          * All patches available via WindowsUpdate also are available in a redistributable form from the WindowsUpdate
            Corporate site.

  Other information:

       Support:

          * Microsoft Knowledge Base article Q322289 discusses this issue. Knowledge Base articles can be found on the
            Microsoft Online Support web site.
          * Technical support is available from Microsoft Product Support Services. There is no charge for support
            calls associated with security patches.

       Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in
       Microsoft products.

       Disclaimer:
       The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind.
       Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and
       fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any
       damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special
       damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages.
       Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the
       foregoing limitation may not apply.

       Revisions:

          * V1.0 (June 06, 2002): Bulletin Created.
          * V2.0 (June 07, 2002): Bulletin updated to alert customers to manually install MS02-026 and make certain
            that VS.NET is closed when applying this patch.

  Contact Us   |   E-mail this Page   |   TechNet Newsletter

  ? 2002 Microsoft Corporation. All rights reserved.     Terms of Use    Privacy Statement    Accessibility