安全公告

Microsoft 安全公告 MS02-028 - 严重

HTR 分块编码中的堆溢出可能导致 Web 服务器泄露（Q321599）

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

版本： 2.1

最初发布： 2002 年 6 月 12 日

更新时间： 2003 年 2 月 28 日

总结

谁应阅读此公告： 使用 Microsoft® Windows NT® 4.0 或 Windows® 2000 托管 Web 服务器的客户。

漏洞的影响： 在系统上运行攻击者选择的代码

最大严重性分级： 严重

建议： 保留 HTR 脚本的业务关键原因的客户应立即应用修补程序。 所有其他应确保禁用 HTR。

受影响的软件：

• Microsoft Internet Information Server 4.0
• Microsoft Internet Information Services 5.0

常规信息

技术详细信息

技术说明：

2002 年 6 月 12 日，Microsoft 发布了本公告的原始版本。 2002年7月1日，公告更新为修订严重性分级。 具体而言，Microsoft 已将此问题的严重性评级提高到“严重”。该修订是为了应对威胁环境中发生重大变化，因为一般情况下对分块编码漏洞的注意力增加，以及发现试图在其他平台上利用类似漏洞的恶意代码。 已禁用 HTR 或应用此修补程序的客户无需执行任何操作。 未禁用 HTR 的客户应尽快这样做。 或者，无法禁用 HTR 的客户应立即应用修补程序。

此修补程序消除了影响 Internet Information Services 的新发现的漏洞。 尽管 Microsoft 通常为 IIS 提供累积修补程序，但在这种情况下，我们提供了一个修补程序，仅消除了此新漏洞，同时完成累积修补程序。 当累积修补程序可供客户使用时，我们将更新此公告，其中包含有关其可用性的信息。 常见问题解答提供了有关漏洞的情况的信息，以及为什么我们相信立即发布单一实例修补程序符合客户的最佳利益。 为了确保服务器完全免受过去和当前漏洞的侵害，强烈建议在安装此修补程序之前安装以前的累积修补程序（在 Microsoft 安全公告 MS02-018 中讨论）。

该漏洞类似于 Microsoft 安全公告 MS02-018 中讨论的第一个漏洞。 与该漏洞一样，此漏洞涉及 IIS 4.0 和 5.0 中区块编码数据传输机制中的缓冲区溢出，并可能用于在系统上溢出堆内存，从而导致 IIS 服务失败或允许代码在服务器上运行。 漏洞之间的主要区别在于，新发现的漏洞在于实现 HTR 的 ISAPI 扩展（一种较旧的、基本上已过时的脚本技术），而前一个扩展位于实现 ASP 的 ISAPI 扩展中。

缓解因素：

• Microsoft 长期以来建议禁用 HTR 功能，除非存在保留它的业务关键原因。 禁用 HTR 的系统不会受到此漏洞的风险。
• 默认情况下， IIS 锁定工具 在所有服务器配置中禁用 HTR。
• 默认情况下， URLScan 工具的当前版本提供了阻止分块编码传输请求的方法。
• 在 IIS 5.0 的默认安装中，利用该漏洞运行代码将授予攻击者IWAM_computername帐户的权限，该帐户仅具有与以交互方式登录的非特权用户相称的权限。

严重性分级：

	Internet 服务器	Intranet 服务器	客户端系统
IIS 4.0	严重	严重	严重
IIS 5.0	严重	严重	严重

上述 评估 基于受漏洞影响的系统类型、其典型部署模式以及利用漏洞对它们的影响。 尽管该漏洞会向成功的攻击者授予不同程度的控制权，但根据正在使用的特定版本，使用任何 Microsoft 安全检查列表或安全工具配置的服务器不会启用 HTR 功能。

漏洞标识符：CAN-2002-0364

测试的版本：

Microsoft 测试了 IIS 4.0、5.0 和 5.1，以评估它们是否受这些漏洞的影响。 以前的版本不再 受支持，可能会或不受这些漏洞的影响。 IIS 6.0 是 beta 产品，beta 产品通常不符合安全修补程序的条件;但是，我们已确认没有受漏洞影响的 IIS 6.0 beta 版本。

常见问题解答

为什么此公告已更新？
2002 年 7 月 1 日，我们更新了此公告，以向客户提供此问题严重性评级的修订建议。 具体而言，由于新信息严重更改了威胁环境，因此我们提高了此问题的评级“关键”。 具体而言，我们意识到了一般情况下围绕分块编码漏洞的兴趣和活动，并意识到尝试在其他平台上利用类似问题。 虽然 Microsoft 目前不知道恶意利用此特定问题的任何尝试，但我们认为此活动构成增加的威胁。 我们已主动将严重性评级修改为“严重”，以更准确地表示此威胁，我们敦促所有客户尽可能立即禁用 HTR 映射。 敦促那些无法禁用 HTR 映射的客户立即应用修补程序。 已采取措施解决此问题的客户无需采取任何措施。

这是累积修补程序吗？
否。 此修补程序消除了新发现的安全漏洞，但它不是累积的。 此问题和其他人的累积修补程序正在开发中，不久将完成。 当它可用时，我们将更新此公告，以提供有关如何获取公告的信息。 由于此修补程序不是累积修补程序，因此我们建议客户在安装此修补程序之前确保已安装最新的累积修补程序（在 Microsoft 安全公告 MS02-018 中提供）。

我认为 Microsoft 的策略是为 IIS 提供累积修补程序。 为什么此修补程序不是累积修补程序？
Microsoft 的正常策略是通过累积修补程序为 IIS 提供安全修补程序。 事实上，累积补丁已经进行了几个星期。 但是，由于累积修补程序的范围和部署范围广，因此需要进行广泛的测试。 因此，累积修补程序离客户就绪还有数周的时间。 新发现的漏洞类似于另一个漏洞（在 Microsoft 安全公告 MS02-018 中讨论），其中已提供攻击工具。 同时，消除仅需要少量代码更改的漏洞，而组件与其他代码几乎没有依赖关系。 因此，我们得出结论，在开发单一实例补丁方面具有很高的价值，我们可以在比平时更短的时间范围内这样做。

如果不想安装修补程序，是否有此漏洞的解决方法过程？
是的。 如上所述，可以通过在 IIS 中禁用很少使用的功能来消除漏洞。 已禁用此功能的客户无需执行任何其他操作。

漏洞的范围是什么？
这是影响 IIS 4.0 和 5.0 的缓冲区溢出漏洞。 通过向受影响的 Web 服务器发送特别选择的请求，攻击者可能会中断 Web 服务，或获得在服务器上运行程序的能力。 此类程序将在 IIS 4.0 中以完整的系统权限运行，但 IIS 5.0 Microsoft 中的特权较少，但尽管如此，Microsoft 也一直建议客户删除包含漏洞的功能，除非存在保留漏洞的业务关键原因，否则这样做的客户不会面临此漏洞的风险。 默认情况下， IIS 锁定工具 禁用此功能。 如 Microsoft 安全公告 MS02-018 中所述，保留了该功能但部署了 URLScan 工具的客户也可能会受到漏洞的保护。

导致漏洞的原因是什么？
由于 ISAPI 扩展中实现 HTR 功能的算术错误，导致漏洞。 具体而言，错误在于一个函数，该函数允许数据通过分块编码上传到 Web 服务器，并导致 IIS 分配大小错误的缓冲区来保存传入数据，结果数据可能会溢出缓冲区的末尾。

什么是 ISAPI 扩展？
ISAPI （Internet Services 应用程序编程接口）是一种技术，它使 Web 开发人员能够通过编写为 Web 服务器提供新服务的自定义代码来扩展其 Web 服务器的功能。 此类代码可以采用以下两种形式之一实现：

• 作为 ISAPI 筛选器 -- 一个动态链接库（.dll），它使用 ISAPI 响应服务器上发生的事件。
• 作为 ISAPI 扩展 -- 一个动态链接库，它使用 ISAPI 提供一组以上和超越 IIS 本机提供的 Web 函数。

对于此漏洞，受影响的代码是一个 ISAPI 扩展，它通过 HTR 实现脚本。

什么是 HTR？
HTR 是作为 IIS 2.0 的一部分交付的第一代高级脚本技术。 HTR 从未被广泛采用，主要是因为一项非常优越的技术， Active Server Pages （）。ASP）是在 IIS 4.0 中引入的，在客户在 HTR 中投入了大量开发资源之前就很受欢迎。 但是，通过版本 5.1 的所有 IIS 版本都支持 HTR，以实现向后兼容性。 Microsoft 长期以来一直主张客户在其 Web 服务器上禁用 HTR，除非对技术有业务关键需求。 默认情况下， IIS 锁定工具 通过取消映射 HTR ISAPI 扩展来禁用 HTR 支持。

HTR 是否有广泛的用途？
目前仍使用 HTR 技术的唯一用途是基于 Web 的密码管理服务。 IIS 附带了一组 HTR 脚本，如果部署了这些脚本，则用户可以通过 Web 服务器更改其 Windows NT 密码，并使管理员能够通过 Web 执行密码管理。 通常，Microsoft 建议禁止通过 Web 执行密码管理。 但是，对于必须执行此操作的客户，我们建议将任何所需的 HTR 脚本转换为 ASP。

什么是分块编码？
Web 服务器通常需要能够接受来自用户的数据。 例如，当网站访问者填写表单并提交表单时，需要将数据上传到服务器，以便处理这些数据。 在这种情况下，将传输的数据量提前已知，服务器可以分配大小正确的缓冲区。 但是，在其他情况下，无法事先知道需要传输多少数据。 例如，应用程序可能会在运行时生成数据，并且可能无法确切地知道它生成的数据量。 HTTP 协议规范提供了一种通过称为分块编码的进程来处理此类数据的方法。 在分块编码中，客户端会生成一个名为区块的数据大小可变数量;然后，它告诉 Web 服务器区块有多大，并发送它。 服务器分配一个缓冲区来容纳传入区块，然后接收并处理它。 当客户端生成其他数据时，它会继续将其聚合成区块并将其传送到服务器。

IIS 4.0 和 5.0 中的 HTR ISAPI 扩展执行分块编码传输的方式有什么问题？
IIS 4.0 和 5.0 HTR 实现中有一个算术错误，导致它们错误地计算传入区块所需的缓冲区大小，并分配太小的缓冲区大小。 结果是区块中的数据可以重叠缓冲区的末尾并覆盖系统内存中的其他数据，从而可能允许修改 IIS 的操作。

可以覆盖多少数据？
根据设计，客户端可以指定任何大小的区块 - 如果服务器不能容纳大区块，则应向客户端发送错误消息。 但是，除了导致分配大小错误的缓冲区外，算术错误还阻止 IIS 4.0 和 5.0 对区块大小施加任何实际限制。 因此，客户端可能会发送一个区块，该区块将覆盖 IIS 进程中的大部分或全部内存。这是一个关键点，因为它会转到此漏洞对服务器构成威胁的核心。 此漏洞是所谓的堆溢出的示例;由于系统内存的动态性质，这些资源比堆栈溢出更难利用，并且可能需要更复杂的技能。 服务器上的数据可以从一刻到下一刻更改位置，从而妨碍攻击者覆盖所选程序或数据的能力。 但是，在这种情况下，攻击者不需要知道程序的位置，而是可以不分青红皂白地覆盖大部分系统内存。

这会使攻击者能够执行哪些操作？
利用此漏洞的攻击者可以将它用于以下两个目的之一。

• 服务中断。 通过用随机数据溢出缓冲区，攻击者可能会损坏程序代码并导致 IIS 服务失败，从而阻止服务器提供有用的服务。
• 更改服务器的操作。 通过用精心选择的数据溢出缓冲区，攻击可能会用新的程序代码覆盖服务器上的程序代码，实际上修改了服务器软件的功能。

谁可以利用漏洞？
能够与受影响的服务器建立 Web 会话的任何用户都可以利用漏洞。

如果漏洞被利用导致 IIS 服务失败，则还原正常操作需要什么？
在 IIS 4.0 上，管理员需要重启 IIS 服务。 在 IIS 5.0 上，服务会自动重启自身。

为什么漏洞只能用于导致 IIS 服务失败？ 如果攻击者能够不分青红皂白地覆盖系统内存，为什么不覆盖服务器上的所有内存并导致整个操作系统失败？
Windows NT 4.0、Windows 2000 和 Windows XP 以 受保护模式运行。 在受保护的模式下，进程只能写入它们拥有的内存部分。 因此，攻击者不可能覆盖属于操作系统的内存。

如果漏洞被利用来更改服务器软件的操作，攻击者将能够做什么？
简言之，攻击者的代码将获取调用它的软件（HTR ISAPI 扩展）的权限。 攻击者可能获取的权限取决于服务器上使用的 IIS 版本：

• 在 IIS 4.0 上，HTR ISAPI 扩展默认在进程内运行，即作为 IIS 服务的一部分运行，作为操作系统本身的一部分运行。 因此，利用默认 IIS 4.0 安装上的漏洞会使攻击者完全控制服务器。
• 在 IIS 5.0 上，HTR ISAPI 扩展默认在进程外运行，即在称为 Web 应用程序管理器的特殊用户帐户的安全上下文中。 （Web 管理员可能更了解此帐户，因为IWAM_计算机名，其中 计算机名 是服务器的名称）。 此帐户的特权明显少于 IIS 服务。

Web 应用程序管理器有哪些特权？
从本质上讲，该帐户具有与能够以交互方式登录服务器的未特权用户的权限相同。 它不允许攻击者执行管理操作、重新配置服务器或访问安全帐户管理器数据库等重要文件。 然而，重要的是不要低估甚至使用这些特权造成的损害。 即使是这些特权也可以用来造成重大损害。 更糟的是，漏洞可能会给攻击者一个海滩头，从中进行额外的攻击，并尝试获得额外的特权。

我正在运行 IIS 4.0。 是否可以将 HTR ISAPI 扩展配置为进程外？
你可以。 但是，更好的解决方案是完全禁用它。

我使用 IIS 锁定工具保护服务器。 它是否禁用 HTR ISAPI 扩展？
是的。 默认情况下，所有版本的 IIS 锁定工具 都会在所有服务器配置中删除 HTR 功能。

我在服务器上部署了 URLScan 工具。 它会保护我的系统免受此漏洞的侵害吗？
从版本 2.5 开始的所有 URLScan 版本都能够阻止分块编码请求。 URLScan 有两种变体，称为“基线 URLScan”和“URLScan-SRP”。 后一个变体默认会阻止分块编码。 可以将前者配置为阻止分块编码，方法是将条目添加到读取“Transfer-Encoding：”的URLScan.ini的 [DenyHeaders] 节。 （注意：不应在条目中包含引号，但在单词“Encoding”的末尾有一个冒号）。

我在 IIS 服务器上禁用了 HTR 功能。 是否需要修补程序？
如果禁用了 HTR 功能，则不会面临此漏洞的风险。

修补程序如何消除此漏洞？
该修补程序消除了导致漏洞的算术错误。

修补程序可用性

下载此修补程序的位置

• Microsoft IIS 4.0：

  https：

• Microsoft IIS 5.0：

  </https：>https：

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

安装平台：

• IIS 4.0 修补程序可以安装在运行 Windows NT 4.0 Service Pack 6a 的系统上。
• IIS 5.0 修补程序可以安装在运行 Windows 2000 Service Pack 1 或 Service Pack 2 的系统上。

包含在将来的 Service Pack 中：

• 没有针对 Windows NT 4.0 计划其他 Service Pack。
• IIS 5.0 修补程序将包含在 Windows 2000 Service Pack 3 中。

需要重新启动：

• IIS 4.0：可以通过停止 IIS 服务、使用 /z 开关安装修补程序，然后重启服务来避免重新启动。 知识库文章Q319733提供有关此过程的其他信息。
• IIS 5.0：否。

取代的修补程序： 无。

验证修补程序安装：

IIS 4.0：

• 若要验证是否已在计算机上安装修补程序，请确认计算机上已创建以下注册表项：

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q321599。

• 若要验证各个文件，请参阅知识库文章Q321599中的文件清单。

IIS 5.0：

• 若要验证是否已在计算机上安装修补程序，请确认计算机上已创建以下注册表项：

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\汇报\Windows 2000\SP4\Q321599。

• 若要验证各个文件，请使用以下注册表项中提供的日期/时间和版本信息：

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\汇报\Windows 2000\SP4\Q321599\Filelist。

注意：

无

本地化：

此修补程序的本地化版本在“修补程序可用性”中讨论的位置可用。

获取其他安全修补程序：

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

• 安全修补程序可从 Microsoft 下载中心获取，可通过执行关键字 (keyword)搜索“security_patch”来轻松找到。
• WindowsUpdate 网站提供了使用者平台的修补程序

其他信息：

确认

Microsoft 感谢eEye Digital Security 向我们报告此问题，并与我们合作保护客户。

支持：

• Microsoft 知识库文章Q321599讨论此问题，此公告发布后大约 24 小时可用。 可以在 Microsoft Online 支持网站上找到知识库文章。
• Microsoft 产品支持服务提供技术支持。 与安全修补程序关联的支持调用不收取任何费用。

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

免责声明：

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

修改：

• V1.0（2002 年 6 月 12 日）：公告已创建。
• V1.1（2002 年 6 月 13 日）：常见问题解答项目已更新。
• V1.2（2002 年 6 月 20 日）：在 IIS 5.0 部分的验证修补程序安装中进行了更正。
• V2.0（2002 年 7 月 1 日）：严重性分级已更新，以反映不断变化的威胁环境。
• V2.1（2003 年 2 月 28 日）：更新了指向Windows 更新的下载链接。

构建于 2014-04-18T13：49：36Z-07：00</https：>