VMware ESXi OpenSLP堆溢出漏洞如何解决

这篇文章主要介绍“VMware ESXi OpenSLP堆溢出漏洞如何解决”的相关知识，小编通过实际案例向大家展示操作过程，操作方法简单快捷，实用性强，希望这篇“VMware ESXi OpenSLP堆溢出漏洞如何解决”文章能帮助大家解决问题。

介绍

• 该漏洞编号为CVE-2021-21974，由 OpenSLP 服务中的堆溢出问题引起，未经身份验证的攻击者可以此进行低复杂度攻击。

• 该漏洞主要影响6.x 版和 6.7、7.0版本之前的 ESXi 管理程序，2021年2月23日 ，VMware曾发布补丁修复了该漏洞。（在此之后发布的版本不影响）

• 该漏洞启动之后，主要破坏行为为停止所有虚拟机，并加密所有数据文件。

• 因为不会加密大文件，所以有很大可能性进行恢复操作。

具体影响版本

大于以下版本则不受影响

• ESXi versions 7.x prior to ESXi70U1c-17325551

• ESXi versions 6.7.x prior to ESXi670-202102401-SG

• ESXi versions 6.5.x prior to ESXi650-202102101-SG

被攻击之后的访问管理界面示例

漏洞成因

服务定位协议

服务定位协议是一种服务发现协议，它允许连接设备通过查询目录服务器来识别局域网内可用的服务。这类似于一个人走进购物中心并查看目录列表以查看商场中有哪些商店。为了保持简短，设备可以通过发出“服务请求”并指定要使用 URL 查找的服务类型来查询服务及其位置。

例如，要从目录服务器查找 VMInfrastructure 服务，设备将使用“service：VMwareInfrastructure”作为 URL 发出请求。服务器将回复类似“service：VMwareInfrastructure：//localhost.localdomain”的内容。

设备还可以通过发出提供相同 URL 的“属性请求”来收集有关服务的其他属性和元数据。要添加到目录中的设备可以提交“服务注册”。此请求将包括发布公告的设备的 IP、服务类型以及要共享的任何元数据等信息。SLP 可以执行更多功能，但我感兴趣的最后一个消息类型是“目录代理通告”，因为这是漏洞所在。“目录代理通告”是由服务器发送的广播消息，让网络上的设备知道如果他们想要查询服务及其位置，应该联系谁。要了解有关 SLP 的更多信息，请参阅此处和该内容。

SLP 数据包结构

虽然不同 SLP 消息类型之间的 SLP 结构布局略有不同，但它们通常遵循标头 + 正文格式。

“服务请求”数据包如下所示：

“属性请求”数据包如下所示：

“服务注册”数据包如下所示：

最后，“目录代理通告”数据包如下所示：

漏洞点

该问题出在“SLPParseSrvURL”函数中，该函数在处理“目录代理通告”消息时被调用。

在第 18 行，URL 的长度与数字相加 0x1d 以形成从内存中“calloc”的最终大小。在第 22 行，调用 'strstr' 函数来查找子字符串 “：/” 的位置在网址中。在第 28 行，子字符串“：/”之前的 URL 内容将从第 18 行复制到新的 ‘calloced’内存中。

另一件需要注意的事情是，如果子字符串“：/”，'strstr'函数将返回0不存在或函数命中空字符。

我推测VMware测试用例只尝试长度小于256的“范围”。如果我们查看以下“目录代理通告”布局代码段，我们会看到示例 1 的“范围”长度包含一个空字节。这个空字节意外地充当了“URL”的字符串终止符，因为它紧随其后。如果 'scopes' 的长度高于 256，则长度的十六进制表示形式将没有空字节（如示例 2 所示），因此 'strstr' 函数将读取传递的 'URL' 并继续查找子字符串 “：/”在“范围”中。

因此，“memcpy”调用将导致堆溢出，因为源包含来自“URL”的内容+“范围”的一部分，而目标只有空格来容纳“URL”。

SLP 对象

在这里，我将介绍相关的 SLP 组件，因为它们是利用的构建块。

_SLPDSocket

连接到“slpd”守护程序的所有客户端都将在堆上创建一个“slpd-socket”对象。此对象包含有关连接的当前状态的信息，例如它是处于读取状态还是写入状态。此对象中存储的其他重要信息包括客户端的 IP 地址、用于连接的套接字文件描述符、指向此特定连接的“recv-buffer”和“send-buffer”的指针，以及指向从先前和将来建立的连接创建的“slpd-socket”对象的指针。此对象的大小固定为 0xd0，无法更改。

来自OpenSLP源代码的_SLPDSocket结构

_SLPDSocket对象的内存布局

_SLPBuffer

从服务器接收的所有 SLP 消息类型将创建至少两个 SLPBuffer 对象。一个称为“recv-buffer”，它存储服务器从客户端接收的数据。由于我可以控制从客户端发送的数据的大小，因此我可以控制“recv-buffer”的大小。另一个SLPBuffer对象称为“send-buffer”。此缓冲区存储将从服务器发送到客户端的数据。“发送缓冲区”具有固定的0x598大小，我无法控制其大小。此外，SLPBuffer 具有元数据属性，指向所述数据的起始位置、当前位置和结束位置。

从 OpenSLP 源代码_SLPBuffer

_SLPBuffer对象的内存布局

SLP 套接字状态

SLP 套接字状态定义特定连接的状态。状态值在_SLPSocket对象中设置。连接将调用“recv”或“发送”，具体取决于套接字的状态。

OpenSLP 源代码中定义的套接字状态常量

了解_SLPSocket、_SLPBuffer和套接字状态的属性非常重要，因为利用过程需要修改这些值。

利用步骤

• 客户端 1 发送“目录代理通告”请求，以准备此特定请求可能发生的任何意外内存分配。我观察到当“slpd”守护进程在启动时运行时运行时，请求会进行额外的内存分配，但在通过 /etc/init.d/slpd start 运行它时不会。任何意外的内存分配最终都会被释放并最终出现在自由列表中。假设这些独特的释放插槽将被未来的“目录代理通告”消息再次使用，只要我没有显式分配会劫持它们的内存。

• 客户端 2–5 发出“服务请求”，每个接收缓冲区的大小为 0x40。这是为了填充自由列表中存在的一些初始释放插槽。如果我不占用这些释放的插槽，它将劫持未来的“URL”内存分配，用于未来的“目录代理通告”消息并破坏堆整理。

• 客户端 6–10 设置客户端 7 以向服务器发送“服务注册”消息。服务器仅接受来自本地主机的“服务注册”消息，因此需要覆盖客户端 7 的“slpd-socket”以更新其 IP 地址。发送消息后，客户端 7 的套接字对象将再次更新，以保存侦听文件描述符以处理未来的传入连接。如果跳过此步骤，将来的客户端将无法与服务器建立连接。

• 客户端 11–21 通过覆盖客户端 15 的“发送缓冲区”位置指针来设置任意读取基元。由于我不知道首先要泄漏哪些地址，因此我将使用空值对“start”位置指针的最后两个有效字节执行部分覆盖。这需要将扩展的空闲块设置为标记为“IS_MAPPED”，以避免被“calloc”调用归零。更新的“发送缓冲区”属于“属性请求”消息。由于我无法了解将泄漏多少数据，因此我可以通过在步骤 3 中记录的“服务注册”消息中包含标记值来大致了解泄漏的位置。如果泄漏的内容包含标记，我知道它正在从“属性请求”“发送缓冲区”对象泄漏数据。这告诉我是时候停止从泄漏中读取了。最后，我必须更新客户端 15 的“slpd-socket”，使其状态为“STREAM_WRITE”，这将向我的客户端发出“发送”调用。

• 我能够从泄漏中收集堆地址和libc地址，我可以得出其他所有内容。我的目标是用libc的系统地址覆盖libc的__free_hook。我将需要一个小工具将我的堆栈放置在应用程序不会更改的位置。我从 libc-2.17.so 中找到了一个小工具，它将堆栈提升堆栈地址0x100。

• 使用收集的libc地址，我可以计算存储堆栈地址的libc环境地址。我使用客户端 22–31 来设置任意读取原语以泄漏堆栈地址。我必须在“slpd-socket”中更新客户端 25 的文件描述符以保存侦听文件描述符。

• 客户端 32–40 设置任意写入基元。这需要覆盖客户端 33 的“recv-buffer”对象的位置指针。它首先将 shell 命令存储到客户端 15 的“发送缓冲区”对象中，这是我控制下的一大块空间。然后，它会在执行堆栈提升后将 libc 的系统地址、虚假返回地址和 shell 命令的地址写入预测的堆栈位置。之后，它会覆盖 libc 的__free_hook以保存堆栈提升小工具地址。最后，每次任意写入都需要将相应的“slpd-socket”对象状态更新为“STREAM_READ”。如果跳过此步骤，服务器将不接受位置指针的覆盖值。

• 完成上述所有步骤后，将执行所需的 shell 命令。

关于“VMware ESXi OpenSLP堆溢出漏洞如何解决”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识，可以关注编程网精选频道，小编每天都会为大家更新不同的知识点。