安全公告

Microsoft 安全公告 MS01-031 - 重要

可预测的名称管道可以通过 Telnet 启用特权提升

发布时间： 2001 年 6 月 7 日 |更新时间：2004 年 4 月 9 日

版本： 1.2

最初发布： 2001 年 6 月 7 日
更新时间： 2004 年 4 月 9 日

总结

谁应该阅读此公告：
使用 Microsoft® Windows® 2000 Telnet 服务的系统所有者

漏洞的影响：
特权提升、拒绝服务、信息泄露

建议：
使用 Telnet 服务的系统所有者应考虑应用修补程序。

受影响的软件：

• Microsoft Windows 2000

常规信息

技术详细信息

技术说明：

本公告讨论了影响 Windows 2000 Telnet 服务的七个漏洞。 这些漏洞分为三大类：特权提升、拒绝服务和信息泄露。

其中两个漏洞可能允许特权提升，并且其根源在于与创建 Telnet 会话的方式相关的缺陷。 建立新的 Telnet 会话后，该服务将创建命名管道，并在初始化过程中运行与其关联的任何代码。 但是，管道的名称是可预测的，如果 Telnet 找到具有该名称的现有管道，则它只是使用它。 在服务器上加载和运行代码的攻击者可以创建管道并将程序与其关联，当 Telnet 服务建立下一个 Telnet 会话时，它将在本地系统上下文中运行代码。

其中四个漏洞可能允许拒绝服务攻击。 这些漏洞都没有任何共同之处。

• 出现这种情况是因为有可能阻止 Telnet 终止空闲会话;通过创建足够数量的此类会话，攻击者可以拒绝与任何其他用户的会话。
• 当 Telnet 会话以某种方式终止时，发生句柄泄漏。 通过反复启动会话，然后终止会话，攻击者可能会耗尽服务器上的句柄供应，使其无法再执行有用的工作。
• 出现这种情况的原因是，包含特定格式错误的登录命令会导致 Telnet 服务中的访问冲突。
• 出现这种情况的原因是系统调用只能使用普通用户特权，这会影响终止 Telnet 会话。

最后一个漏洞是信息泄露漏洞，使攻击者更容易找到通过 Telnet 服务器公开的来宾帐户。 它与影响 FTP 的漏洞具有相同的原因、范围和效果，并在 Microsoft 安全公告 MS01-026 中讨论。

缓解因素：

特权提升漏洞：

• 由于攻击者需要能够在 Telnet 服务器上加载和运行代码，因此，只有能够在本地在 Telnet 服务器上运行代码的攻击者才能利用这些漏洞。
• 需要管理员特权才能启动 Telnet 服务，因此，如果计算机上已启动 Telnet，攻击者只能利用漏洞。

拒绝服务漏洞：

• 无需重新启动服务器即可从其中任何漏洞中恢复。 最坏的情况是，需要重启 Telnet 服务。
• 这些漏洞都不能用于获取计算机上的其他权限;它们仅拒绝服务漏洞。

信息泄露漏洞：

• 仅当本地计算机上的来宾帐户已禁用，但启用了受信任域上的来宾帐户时，才能利用该漏洞。 默认情况下，来宾帐户处于禁用状态。

漏洞标识符：

特权提升漏洞：

• CAN-2001-0349
• CAN-2001-0350

拒绝服务漏洞：

• CAN-2001-0345
• CAN-2001-0346
• CAN-2001-0348
• CAN-2001-0351

信息泄露漏洞：

• CAN-2001-0347

测试的版本：

Microsoft 测试了 Windows 2000 和 Windows NT® 4.0，以评估它们是否受此漏洞的影响。 以前的版本不再受支持，可能或可能不会受到此漏洞的影响。

常见问题解答

此公告中讨论的漏洞是如何相互关联的？
这些漏洞彼此无关，除非所有这些漏洞都涉及 Windows 2000 Telnet 服务。

什么是漏洞？
这里共有七个漏洞，分为三个常规类别：

• 两个漏洞，使攻击者能够在 Telnet 服务器上获得特权。
• 四个可用于中断 Telnet 服务的漏洞。
• 一个漏洞，可以使攻击者更容易通过 Telnet 服务访问配置不佳的网络。

第一组漏洞的范围是什么？
前两个漏洞是特权提升 漏洞。 利用这两个漏洞中的任何一个，攻击者都可以完全控制受影响的服务器，并使她能够对它采取任何所需操作。 这些漏洞存在重大限制 - 利用任一漏洞都要求攻击者已经能够将自己选择的程序放入服务器并运行它。 在大多数情况下，这要求攻击者对受影响的服务器拥有本地登录权限。

导致漏洞的原因是什么？
这两个漏洞都由于 Telnet 服务处理服务器端命名管道的方式存在相同的根本问题。 通过类似于 Microsoft 安全公告 MS00-053 中讨论的缺陷，Telnet 可以使用攻击者创建的命名管道，从而导致 Telnet 执行命名管道中包含的任何代码。

什么是命名管道？
管道是两个或多个进程共享的内存区域，使它们能够相互通信。 当进程 A 想要与进程 B 通信时，它将数据放入共享内存中，并设置信号灯，告知进程 B 读取它。 管道分为两种类型：

• 匿名管道，允许从父进程到子进程的单向通信。 它们只能存在于本地。
• 命名管道，允许在多个进程之间进行双向通信。 这些进程可以驻留在不同的计算机上。

这两个漏洞是由于 Telnet 服务在启动新的 Telnet 会话时处理命名管道的方式导致的。

Telnet 使用命名管道的方式有什么问题？
每当 Telnet 启动一个新会话时，它都会创建一个命名管道并将其分配给会话。 附加到命名管道的任何代码都作为初始化过程的一部分执行。 漏洞会导致漏洞，因为 Telnet 为管道选择可预测的名称，如果存在具有指定名称的管道，Telnet 将使用它。

为什么这会导致一对安全漏洞？
由于 Telnet 的命名算法是可预测的，因此攻击者可能会猜测服务器将用于它建立的下一个 Telnet 会话的管道的名称。 这将使她有机会提前创建管道，并向其附加她选择的代码。 如果她这样做，Telnet 服务将使用管道并为她运行代码。

代码在哪个安全上下文中运行？
代码将在 Telnet 服务的安全上下文中运行 - 本地系统。 这会使攻击者的代码能够在服务器上执行任何所需操作。

这两个漏洞有何区别？
这两个漏洞的主要区别在于它们利用有关命名管道创建的基本问题的方式。

漏洞是否会使攻击者接管整个域？
域的风险取决于被入侵的特定计算机，以及它在网络上扮演的角色。 如果独立服务器遭到入侵，它可能会对网络造成很小的风险，因为默认情况下，即使是本地管理员也没有特殊的域特权。 但是，如果本地存储域管理信息的域控制器或其他计算机遭到入侵，恶意用户可以利用它将控制权扩展到本地计算机之外。 但是，域控制器和类似计算机存储域管理信息是建议的安全做法建议不要将其用作 Telnet 服务器的原因之一。

攻击者如何创建命名管道？
命名管道只能在程序控制下创建，并且只能在本地计算机上创建。 这是一个重要点，因为它意味着攻击者只有在能够将程序加载到服务器上并运行它时，才能利用漏洞。 通常，这要求攻击者能够以交互方式登录到服务器。 但是，最佳做法强烈建议用户以交互方式登录到此类服务器。 如果遵循了此建议，攻击者将无法利用任一漏洞。

攻击者是否可以通过 Telnet 会话利用这些漏洞？
尽管这些漏洞涉及 Telnet 服务，但攻击者不太可能通过 Telnet 会话利用任一漏洞。 Telnet 会话可能会向攻击者提供运行程序的方法，但不会让她以任何方式将程序加载到服务器上。 这是攻击者可能需要交互式登录权限才能利用漏洞的主要原因

如果无法通过 Telnet 会话利用它们，他们怎么能被利用？
最有可能的利用方案是涉及双用计算机（例如，运行 Telnet 服务的终端服务器，例如，允许管理员远程管理它）。

如果攻击者已经拥有对计算机的交互式登录权限，她是否可以将 Telnet 服务作为利用漏洞的方法启动？
请记住，启动 Telnet 服务需要管理访问权限。 如果攻击者能够在计算机上启动 Telnet，她根据定义已经完全控制了计算机。

修补程序如何消除漏洞？
修补程序消除了漏洞，提高了 Telnet 服务选择命名管道名称的随机性。

第二组漏洞的范围是什么？
这些是 拒绝服务 漏洞。 这些漏洞可能导致攻击者通过垄断服务器资源、中断服务器操作或访问应拒绝给非特权用户的管理功能来防止合法用户使用 Telnet 服务器。 以下部分讨论每个漏洞。

是什么导致了第一个拒绝服务漏洞，攻击者如何利用它？
此漏洞会导致此问题，因为有可能阻止空闲的 Telnet 会话超时。通过启动服务器可以容纳的任意数量的会话，并让他们以特定方式空闲，攻击者可能会阻止其他用户建立 Telnet 会话。

是什么原因导致第二个拒绝服务漏洞，攻击者如何利用它？
此漏洞导致的原因是，当以特定方式切断 Telnet 会话时，不会将调用句柄的某些资源返回到系统以供重复使用。 通过反复建立和断断 Telnet 会话，攻击者可能会耗尽服务器资源，达到服务器可能无响应或完全失败的地步。 管理员可以通过重启 Telnet 会话来还原正常服务。

导致第三个拒绝服务漏洞的原因，攻击者如何利用它？
此漏洞导致 Telnet 服务无法正确处理包含特定畸形的登录命令。 如果攻击者输入了此类命令，则会导致 Telnet 服务失败。 管理员可以通过重启 Telnet 会话来还原正常服务。

是什么导致了第四个拒绝服务漏洞，攻击者如何利用它？
此漏洞会导致此错误，因为尽管 Telnet 服务的管理控制台需要管理权限，但某些基础系统调用没有。 具体而言，使用正常特权运行的程序可能会发出系统调用来终止 Telnet 会话。 如果攻击者能够在 Telnet 服务器上加载和运行程序，她可以终止她想要的任何 Telnet 会话。

这些漏洞是否会阻止服务器执行其他工作？
只有第二个漏洞会妨碍服务器执行其他工作。 对于其他三个漏洞，服务器将继续正常运行，除非 Telnet 服务会中断。

这些漏洞是否使攻击者能够获得对计算机的管理控制？
否。 这些攻击只是拒绝服务攻击，并且不会为攻击者提供任何方法来提升她在计算机上的特权、泄露数据或采取任何其他操作。

这些漏洞是否可以从 Internet 利用？
前三个漏洞可能会被利用到 Internet 连接的服务器。 但是，第四个漏洞要求攻击者能够将程序加载到服务器上并运行它。 在大多数情况下，这要求她能够以交互方式登录到服务器。

修补程序如何消除这些漏洞？

• 该修补程序通过导致空闲超时时钟在所有条件下运行来消除第一个漏洞。 这可确保空闲会话终止。
• 修补程序通过确保分配给 Telnet 会话的所有资源在会话结束时返回到操作系统，从而消除了第二个漏洞。
• 该修补程序通过将已变形的登录命令视为无效的登录命令来消除第三个漏洞。
• 该修补程序通过将安全检查从管理控制台移动到基础系统调用来消除第四个漏洞。

最终漏洞的范围是什么？
这是信息泄露漏洞。 它不会给攻击者一种执行她无法执行的任何操作的方法，但这将使她更容易利用配置错误的网络。 在最坏的情况下，该漏洞可以帮助攻击者获取对域帐户的访问权限。 此漏洞存在许多重大限制：

• 攻击者需要知道帐户的正确密码。 默认情况下，最可能受影响的帐户 -- 来宾帐户 - 已禁用。
• 仅当系统管理员将 Telnet 服务器设为域成员时，才能利用该漏洞。

此漏洞听起来很熟悉。 它是否类似于以前讨论的漏洞？
是的。 事实上，它与影响 FTP 服务的信息泄露漏洞精确相似，该漏洞在 Microsoft 安全公告 MS01-026 中进行了讨论。

导致漏洞的原因是什么？
漏洞的原因是，如果用户登录到受影响的 Telnet 服务器时以特定方式指定了 userid，则系统会自动搜索所有受信任的域以获取与其匹配的 userid。 如果找到 userid 并提供正确的密码，系统将允许用户正常登录。

你对受信任的域意味着什么？
Windows NT 和 Windows 2000 中的域可以进入信任关系，以便允许一个域中的用户访问另一个域中的资源。 例如，域 A 的管理员可能同意信任域 B，从而允许域 B 中的用户访问和使用域 A 中的服务器、文件和其他资源。这称为信任关系，因为域 A（信任域）在为用户标识提供担保时同意信任域 B（受信任域）。

这与 Telnet 有什么关系？
域信任对 Telnet 很重要，因为它们会影响谁可以登录到 Telnet 服务器。 用户始终可以通过本地服务器本身的用户帐户登录到 Telnet 服务器。 但是，如果服务器是域成员，用户还可以通过其中一个域用户帐户登录到服务器。 最后，如果服务器是信任另一个域的域的成员，则用户可以通过某个受信任的域的用户帐户登录到服务器。 当然，用户需要知道她想要登录的任何用户帐户的密码。

服务器如何知道是将用户登录到本地用户帐户还是域帐户？
这取决于用户输入帐户名的方式。 如果她本身只输入了帐户名（例如“Jane”），则服务器会尝试使用本地帐户将她登录到服务器。 如果她想要登录到域帐户，她需要用域名（例如 DomainA\Jane）为用户帐户名加上前面。

用户是否有办法确定哪些帐户可用？
根据设计，用户不应确定本地计算机上、计算机所属域中或任何受信任域中存在哪些帐户。 用户应该已经知道用户帐户名称和域名才能开始登录过程。 此漏洞不会消除此安全措施，但它确实会削弱它。

漏洞是什么？
如果用户输入以特定字符集开头的用户帐户名称，Telnet 服务将不需要她提供帐户所属的域的名称。 相反，它将搜索服务器的域及其信任的所有域，以获取与用户输入的用户名匹配的用户帐户名。 如果找到一个帐户，并且用户输入该帐户的正确密码，则会将她登录到服务器。

这有什么不好的？ 毕竟，用户确实知道密码。 用户不应在不知道并指定域名的情况下登录到域用户帐户。 当然，攻击者始终可以进行暴力攻击，只需尝试每个可能的域名和用户帐户名称。 但是，此漏洞显然会使攻击更加容易。

但是，用户仍然需要知道或猜测有效的域用户帐户的名称，对吗？
正确，因此，此漏洞可能仅在几个方案中有用。 具体而言，它有助于装载涉及来宾帐户的攻击，因为该帐户既具有已知帐户名，又具有已知密码。 如果启用，来宾帐户的默认密码为空。 若要查看为什么这会为攻击者提供优势，假设 Telnet 服务器是信任其他 20 个域的域的成员，并且假设 Domain15 中的来宾帐户无意中已启用。 如果攻击者输入“Guest”作为帐户名称（当然由正确的字符开头），则此漏洞将导致 Telnet 服务搜索所有受信任的域，然后将用户登录到 Domain15\Guest。 输入空白密码后，攻击者将获取对 Domain15\Guest 帐户的访问权限。

但假设本地计算机上的来宾帐户已禁用。 那么呢？
它不会阻止攻击者登录到 Domain15\Guest。 但是，此问题有一个方面值得考虑。 如果已启用本地计算机上的来宾帐户，则无法利用该漏洞，因为 Telnet 服务会尝试将攻击者登录到本地来宾帐户。

但是，如果我启用本地来宾帐户，我仍然会向不受信任的用户授予对服务器的访问权限，我不会吗？
实际上，你不会。 即使已启用 Telnet 服务，Telnet 服务也不会允许登录到本地来宾帐户。 换句话说，如果启用了本地来宾帐户，则会阻止攻击者利用此漏洞，但仍不允许他登录到本地来宾帐户。 当然，防止漏洞的最佳方法是应用修补程序。

如果攻击者利用此漏洞并获得了对域来宾帐户的访问权限，攻击者该怎么办？
这取决于帐户在域上授予的权限。 在上面的示例中，攻击者能够执行允许域 15\来宾帐户执行的任何操作。 通常，来宾帐户具有很少的权限，但它是“每个人”组的成员，因此可以查看、添加或更改某些文件。

假设 Domain15\Guest 帐户已配置为具有非空白密码。 那么呢？
除非她知道密码，否则攻击者无法登录。 此漏洞中没有任何内容允许攻击者了解帐户的密码。 事实上，这就是为什么我们专注于来宾帐户的讨论 - 这是少数几个，如果启用，有一个已知的默认密码。

修补程序的作用是什么？
修补程序将 Telnet 服务返回到其按设计操作，并导致它仅在正确指定域名时将用户登录到域帐户。

修补程序可用性

下载此修补程序的位置

• Microsoft Windows 2000 Professional、Server、Advanced Server：
  https://www.microsoft.com/download/details.aspx?FamilyId=0D0032E7-259D-4F68-BF08-B0A7CAA1FD1C&displaylang;=en

• Microsoft Windows 2000 Datacenter Server：
  Windows 2000 Datacenter Server 的修补程序特定于硬件，可从原始设备制造商获取。

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

安装平台：

此修补程序可以安装在运行 Windows 2000 Service Pack 1 和 Service Pack 2 的系统上。

包含在将来的 Service Pack 中：

此问题的修补程序将包含在 Windows 2000 Service Pack 3 中。

取代的修补程序：

此修补程序取代 MS00-050 发布的修补程序。

需要重新启动： 否

验证修补程序安装：

• 若要验证是否已在计算机上安装修补程序，请确认计算机上已创建以下注册表项：
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\汇报\Windows 2000\SP3\Q299553

• 若要验证各个文件，请使用以下注册表项中提供的日期/时间和版本信息：
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\汇报\Windows 2000\SP3\Q299553\Filelist

注意：

无

本地化：

此修补程序的本地化版本正在开发中。 完成后，它们将出现在“获取其他安全修补程序”中讨论的位置。

获取其他安全修补程序：

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

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

其他信息：

确认

Microsoft 感谢 以下人员与我们合作来保护客户：

• 用于报告两个特权提升漏洞和一个拒绝服务漏洞的 Guardent （www.guardent.com ）。
• Securexpert 的 Richard Reiner，用于报告其中一个拒绝服务漏洞。
• Bindview 的 Razor 团队报告其中一个拒绝服务漏洞。
• Peter Grundl 报告其中一个拒绝服务漏洞。

支持：

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

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

免责声明：

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

修改：

• V1.0（2001 年 6 月 7 日）：公告已创建。
• V1.1（2003 年 2 月 28 日）：更新了常见问题解答部分中的链接。
• V1.2（2004 年 4 月 9 日）：更新了 Service Pack 版本的修补程序信息部分。

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