Microsoft安全公告 MS02-026 - 中等

ASP.NET 工作进程中未选中的缓冲区(Q322289)

发布时间: 2002 年 6 月 6 日 |更新时间:2003 年 2 月 28 日

版本: 2.1

最初发布: 2002 年 6 月 6 日

更新时间: 2003 年 2 月 28 日

总结

谁应阅读此公告: 运行 ASP.NET 应用程序的 Web 服务器的客户。

漏洞的影响: 拒绝服务,可能运行攻击者选择的代码。

最大严重性分级: 中等

建议: 使用 StateServer 模式的客户应应用修补程序。 不使用 StateServer 模式的客户无需采取任何操作。

受影响的软件:

  • Microsoft .NET Framework 版本 1.0,其中 ASP.NET 是组件。

常规信息

技术详细信息

技术说明:

ASP.NET 是一系列技术,可帮助开发人员构建基于 Web 的应用程序。 基于 Web 的应用程序(包括使用 ASP.NET 生成的应用程序)依赖于 HTTP 来提供连接。 HTTP 作为协议的一个特征是,它是无状态的,这意味着从用户到站点的每个页面请求都被视为独立的请求。 为了弥补这一点,ASP.NET 通过各种模式提供会话状态管理。

其中一种模式是 StateServer 模式。 此模式将会话状态信息存储在单独的正在运行的进程中。 该进程可以在同一台计算机或与 ASP.NET 应用程序不同的计算机上运行。 在 StateServer 模式下处理 Cookie 的例程中有一个未选中的缓冲区。 安全漏洞会导致安全漏洞,因为攻击者可以通过装载缓冲区溢出攻击来寻求利用它。 成功的攻击可能导致 ASP.NET 应用程序重启。 因此,基于 Web 的应用程序的所有当前用户将看到其当前会话重启,其当前会话信息将丢失。

StateServer 模式不是 ASP.NET 中会话状态管理的默认模式。 ASP.NET 使用不使用 Cookie 的 StateServer 模式的应用程序不易受攻击。

缓解因素:

  • StateServer 模式不是 ASP.NET 中的会话状态管理的默认模式。 ASP.NET 应用程序必须专门配置为使用此模式。
  • 即使应用程序配置为使用 StateServer 模式,它也在使用 Cookie 时才会面临风险。

严重性分级:

Internet 服务器 Intranet 服务器 客户端系统
ASP.NET 适中 适中

上述 评估 基于受漏洞影响的系统类型、其典型部署模式以及利用漏洞对它们的影响。 仅通过将 StateServer 模式与 Cookie 结合使用来公开漏洞。 StateServer 模式不是会话状态管理的默认会话状态模式。

漏洞标识符:CAN-2002-0369

测试的版本:

Microsoft测试了 .NET Framework 1.0,以评估它们是否受此漏洞的影响。 没有 .NET Framework 的易行版本。

常见问题解答

漏洞的范围是什么?
这是缓冲区溢出漏洞。 能够成功利用此漏洞的攻击者可能导致 Web 服务器上运行的应用程序重启。 此外,虽然Microsoft无法演示,但攻击者有可能利用此漏洞在 Web 服务器上运行代码。 该代码可以在 ASP.NET 工作进程的安全上下文中运行,该进程默认使用未特权帐户。 此漏洞仅影响使用 StateServer 模式管理会话状态信息的 ASP.NET 应用程序。 这不是默认模式。 最后,只会影响那些使用 Cookie 的 StateServer 模式的应用程序。 在没有 Cookie 的情况下使用 StateServer 模式的应用程序不受漏洞的影响。

导致漏洞的原因是什么?
漏洞结果是因为处理 ASPState 服务中的 Cookie 数据的函数无法正确检查传递给它的 Cookie 的长度。

什么是 ASP.NET?
ASP.NET 是 .NET Framework 中的技术集合,使开发人员能够生成 Web 应用程序和 XML Web 服务。 与传统网页(使用静态 HTML 和脚本组合)不同,ASP.NET 使用已编译的事件驱动页面。 这样,开发人员就可以生成具有相同丰富性和功能的基于 Web 的应用程序,这些应用程序通常与使用 Visual Basic 或 Visual C++ 等语言生成的应用程序相关联。 但是,与桌面应用程序不同,这些合规页面使用 HTML 和 XML 等标记语言生成发送到客户端桌面或浏览器的信息。 这使开发人员可以生成具有广泛功能的应用程序,但可将用户界面投影到运行许多操作系统的设备和系统。 由于 ASP.NET 是基于 Web 的应用程序环境,因此它需要基础 Web 服务器来提供基本的 HTTP 功能。 因此,ASP.NET 在 Windows 2000 上的 IIS 5.0 和 Windows XP 上的 IIS 5.1 上运行。 此特定情况下的问题涉及如何 ASP.NET 处理 HTTP 功能的各个方面:会话状态。

什么是 SessionState?
ASP.NET 应用程序是基于 Web 的应用程序。 因此,它们基于与传统 Web 应用程序相同的基本概念构建。 其中最重要的概念之一是会话状态。 根据设计,超文本传输协议(HTTP)是无状态协议。 这意味着,从网络层的角度来看,Web 服务器和 Web 浏览器之间的每个交互都是一个单独的不相关的交互。 例如,假设你查看一个网页,该网页列出了在线鞋零售商尺寸中的所有鞋。 假设你随后单击某个特定鞋以显示其特定页面。 从 Web 服务器的角度来看,这两种交互彼此完全无关:它们是两个完全独立的交换。 Web 服务器无法知道这些请求是同一用户会话的一部分。 由于用户与网站(而不是网页)交互,因此引入了 Cookie 来帮助克服此限制。 Cookie 引入了 href=“https://msdn2.microsoft.com/library/ms952598.aspx"的概念<;>通过为 Web 服务器提供将单个用户的各个页面请求关联到更有意义的整体会话的方法,会话状态。

什么是 Cookie?
Cookie 是存储在用户的本地系统上的数据文件。 它们是结构和内容中的自由形式:网站可以选择在 Cookie 中存储他们选择的任何信息。 但是,由于信息始终以明文形式传递,因此可以识别到敏感信息不应存储在 Cookie 中。

CookiesEnableSessionState 如何
HTTP 是无状态协议,这意味着 Web 服务器无法将多个页面请求与单个会话相关联。 由于 Cookie 为网站提供了一种在客户端上存储数据的方法,因此它们提供了一种克服此限制的方法。 网站可以使用 Cookie 来存储可用于关联站点上的多个请求以创建单个整体会话的信息。 从本质上讲,一页可以在 Cookie 中记下,然后可由另一页读取。 然后,这会有效地创建会话。 例如,如果选择购买一双鞋子,零售商的网站可以在所选鞋的饼干中记下。 然后转到结帐页面时,它可以读取 Cookie 以查看已购买的项目。 然后,它可以为多个页面上选择的项目生成单个页面。

如何在服务器上处理 SessionState
虽然 Cookie 存储在本地计算机上,但首次使会话状态成为可能,但状态管理最终由 Web 服务器而不是客户端驱动。 Web 服务器必须知道如何使用状态信息。 此外,不同的应用程序对使用状态信息有不同的要求。 最终,这意味着在服务器上处理此信息的方式将存在差异。 为此,ASP.NET 引入了多种不同的会话状态管理方式,以满足应用程序的不同要求。 例如,在单个服务器上托管的在线鞋类零售应用程序在管理会话状态方面要求不同于服务器场中托管的应用程序。

ASP 如何。NETManageSessionState?
除了完全依赖 Cookie 来管理会话状态信息之外,ASP.NET 还提供了一个选项,允许在服务器上管理部分或所有会话状态信息。 这可以通过减少 Web 服务器和客户端之间必须交换的信息量来提高性能。 ASP.NET 提供了三种方法来管理服务器上的会话状态信息

  • 进程内模式。
  • 进程外模式(也称为 StateServer 模式)
  • SQL Server 模式

进程内模式将会话状态信息存储在与 ASP.NET 应用程序本身相同的正在运行的程序中。 这具有速度优势,因为会话信息立即可供应用程序使用。 其缺点是不能在 Web 场上使用,因为信息包含在单个计算机上。 这是 ASP.NET 应用程序的默认会话状态。 StateServer 模式将会话状态信息存储在单独的正在运行的程序 ASPState 服务中。 这可以在与 ASP.NET 应用程序不同的系统上运行。 这样做的优点是,它可以支持 Web 场方案。 SQL Server 模式类似于 StateServer 模式,因为它支持 Web 场方案。 在这种情况下,会话状态信息存储在数据库服务器上,可由应用程序场的任何成员访问。 由于 SQL Server 的可伸缩性,这是在 Web 场方案中管理会话状态信息的首选选项。

StateServer 模式如何处理 Cookie 有什么问题?
StateServer 模式函数中的一个函数中有一个未选中的缓冲区,用于处理 cookie 的处理,当它们呈现给 ASP.NET 时。

怎么会出现这种情况? 我认为 .NET Framework 中不可能有未检查的缓冲区?
虽然 StateServer 本身是使用 .NET Framework 编写的,但它调用的一些帮助程序函数不是使用 .NET Framework 编写的。 导致漏洞的缺陷位于使用传统代码编写的其中一个帮助程序函数中。 但是,计划将所有函数迁移到 .NET Framework。 这项工作目前正在进行中。 因为这是一个体系结构更改,而不是可以在安全修补中安全地进行的更改类型,因此这项工作的结果将在第一个可用的大型船舶车辆中做出。

因此,此漏洞根本不影响 .NET Framework 托管代码?
正确。 该漏洞与 .NET Framework 的托管代码无关。

此漏洞使攻击者能够执行哪些操作?
攻击者可能试图利用此漏洞并装载缓冲区溢出攻击。 成功的攻击可能导致 ASP.NET 应用程序重启。 此外,尽管Microsoft无法在测试中重现代码的执行,但我们认为攻击者仍有可能利用此漏洞并导致代码执行。 但是,默认情况下,ASP.NET 工作进程在非特权安全上下文中运行。 因此,如果攻击者能够通过此漏洞引入所选代码,攻击者的代码将在系统上以非常有限的能力运行。

攻击者如何利用此漏洞?
攻击者可以通过创建格式特别不正确的 Cookie 并将该 Cookie 呈现给 ASP.NET 应用程序来寻求利用此漏洞。 当 ASP.NET 应用程序和缓冲区溢出处理 Cookie 时,ASP.NET 应用程序将重启。

你说,只有将 StateServer 与 Cookie 结合使用的应用程序可能会易受攻击,你能提供更多的详细信息吗?
由于导致漏洞的缺陷与 StateServer 模式下 Cookie 的处理相关,因此使用 StateServer 模式但不使用 Cookie 的任何 ASP.NET 应用程序都不会公开该漏洞。

修补程序的作用是什么?
该修补程序通过对 StateServer 模式下处理的 Cookie 实施适当的检查来消除漏洞。

我使用的是 StateServer 模式,但未使用 Cookie,我应该应用修补程序吗?
是的。 如果要使用 StateServer 模式(即使没有 Cookie),则应应用修补程序,以确保在决定随时使用 Cookie 时解决漏洞。 但是,还应考虑改用 SQL Server 模式。

修补程序可用性

下载此修补程序的位置

有关此修补程序的其他信息

安装平台:

可以在运行 .NET Framework 版本 1.0 SP1 的系统上安装此修补程序

包含在将来的 Service Pack 中:

此问题的修补程序将包含在 .NET Framework Service Pack 2 中。

需要重新启动:

取代的修补程序: 无。

验证修补程序安装:

  • 若要验证是否已在计算机上安装修补程序,请确认计算机上已创建以下注册表项:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\。NETFramework\1.0\NDP10SP317396\M322289。

注意:

  • Microsoft了解了以无提示方式安装 MS02-026 并打开 VS.NET 的用户可能会遇到系统不稳定。 安装 MS02-026 修补程序时,如果在安装修补程序期间锁定受影响的文件,则安装可能无法正确完成。 当修补程序安装以无提示模式运行且文件处于锁定状态或修补程序以非无提示模式运行并且提示关闭锁定文件的应用程序时,可能会发生这种情况。 Microsoft鼓励用户在运行 VS.NET 时不要安装修补程序。 有关详细信息,请参阅Q324292。

本地化

此修补程序的本地化版本在“获取其他安全修补程序”中所述的位置提供。

获取其他安全修补程序:

可从以下位置获取其他安全问题的修补程序:

其他信息:

支持

  • Microsoft知识库文章Q322289讨论此问题。 可以在Microsoft联机支持网站上找到知识库文章。
  • Microsoft产品支持服务提供技术支持。 与安全修补程序关联的支持调用不收取任何费用。

安全资源:Microsoft TechNet 安全网站提供有关Microsoft产品安全性的其他信息。

免责声明

Microsoft知识库中提供的信息“按原样”提供,不提供任何形式的担保。 Microsoft明示或默示地否认所有担保,包括适销性和针对特定用途的适用性的保证。 在任何情况下,Microsoft公司或其供应商应承担任何损害,包括直接、间接、附带、后果性、业务利润损失或特殊损害,即使Microsoft公司或其供应商被告知存在此类损害的可能性。 某些州不允许排除或限制后果性或附带性损害的责任,因此上述限制可能不适用。

修改:

  • V1.0 (2002 年 6 月 6 日):公告已创建。
  • V2.0(2002 年 6 月 7 日):公告已更新,提醒客户手动安装 MS02-026,并确保应用此修补程序时关闭 VS.NET。
  • V2.1(2003 年 2 月 28 日):更新了指向Windows 更新的下载链接。

生成于 2014-04-18T13:49:36Z-07:00