Pwn2Own 大赛赐我灵感，让我发现仨Oracle VirtualBox 漏洞，其中俩提权

 聚焦源代码安全，网罗国内外最新资讯！

作者：MAX VAN AMERONGEN

编译：代码卫士

对我来说，Pwn2Own 大赛就像圣诞节。比赛让人兴奋不已，大家四处搜寻着最常用也是难度最高的软件中的严重漏洞。今年3月份为温哥华大赛准备期间，我决定不写浏览器fuzzer了，打算换个方向：VirtualBox。

虚拟化是极其有趣的目标，它的复杂度尤其高，同时涉及模仿硬件设备以及安全地将数据传递到真正的硬件中。就像箴言说的那样：有复杂性存在的地方，就有 bug。

对于 Pwn2Own 大赛而言，针对被模拟组件发起冲击是一种安全的做法。我认为网络硬件模拟像是正确的也常见的路径。我从一个默认组件起步：/src/VBox/Devices/Network/DrvNAT.cpp 中的NAT 模拟代码。

当时我只是想找找代码感觉，于是只是用鼠标滚动着翻看了文件并阅读了多个部分，并没有采取特定的方法。在这个过程中，下面代码引起了我的注意。

用于从guest 向网络发送数据包的函数中包含着Generic Segmentation Offload (GSO) 框架的单独代码路径，而且使用memcpy 连接数据。

当然，下一个问题就是“我能控制多少？”，我查看了多种代码路径并为所有限制因素编写了简单的 Python 约束求解器后，当我使用半虚拟化网络 ( Paravirtualization Network) 设备 VirtIO 时，得到了这个问题的答案，那就是“比我预想的还要多”。

除了完整模拟一台设备外，还有一个选择就是使用半虚拟化。全虚拟化是指 guest 完全未意识到自己是一个guest，而半虚拟化则是guest 安装驱动意识到自己在guest 机器中运行，以便更快速更高效地与主机一起传输数据。

VirtIO 是一个接口，可用于开发半虚拟化的驱动。Virtio-net 就是这样一种驱动，它的来源是 Linux 且用于网络。VirtualBox 和其它虚拟化软件一样，将这类驱动当作网络适配器：

像 e1000那样，VirtIO 网络使用环形缓冲区在guest和host之间传输数据（本案例中是 Virtqueues 或 VQueues）。然而，和e1000不同的地方在于，VirtIO 传输时使用的不是缓存器头尾相连的单个环形，而是使用了三个不同的数组：

如下所示：

当guest 希望向网络发送数据包时，它会在装饰器表格中增加一个条目，将该装饰器的索引增加到 Available 环形，之后增加 Available Index 指针：

之后，guest 将 VQueue 索引写入 Queue Notify 存储器“踢出”主机。这使得主机开始处理 Available 环形中的装饰器。当装饰器被处理后，它就会被添加到 Used 环形，而 Used Index 增加：

先来介绍一下通用分段卸载 (Generic Segmentation Offload) 的背景，要理解GSO，需要理解它为网卡解决的问题。

最初CPU 在计算传输层校验和时会处理所有负担，或者将它们分段为更小的以太网数据包大小。这个流程在处理很多出站网络流量时可能非常缓慢，因此硬件制造商开始卸载这些操作，以消除操作系统的压力。

而非那段意味着操作系统不必通过网络栈传递更小的数据包，而只需一次传递一个数据包。这种优化同样适用于除了TCP和UDP以外的协议，只有在网络驱动接收报文时才需要通过延迟分段提供硬件支持，这就是创建GSO的契机。

由于 VirtIO 是一种半虚拟化设备，因此驱动意识到它位于guest机器中，因此GSO可适用于guest和host 之间。GSO通过在网络缓冲区开头添加上下文装饰器标头的方式在 VirtIo 中执行。如下 struct 说明了该标头：

VirtIO 标头可视作与 e1000 中 Context Descriptor 类似的概念。当接收到标头时，vnetR3ReadHeader 会验证参数的合法性。之后，函数 vnetR3SetupGsoCtx 用于填充所有网络设备中 VirtualBox 使用的标准 GSO 结构：

完成上述构建后，VirtIO 代码创建 scatter-gatherer 从多种装饰器中汇编该框架：

该框架连同新的GSO结构被传递给NAT代码，进而引起我的注意。

CVE-2021-2145：Oracle VirtualBox NAT 整数下溢提权漏洞

当NAT代码接收到GSO框架时，它获得了完整的以太网数据包并将其传递给 Slirp （TCP/IP 模拟库）作为mbuf 报文。为此，VirtualBox 分配了一个新的 mbuf 报文并将数据包拷贝到该报文中。该分配函数占一个大小，之后从三个不同的存储桶中挑选了下一个最大的分配大小：

1、MCLBYTES（0x800 字节）

2、MJUM9BYTES（0x2400 字节）

3、MJUM16BYTES（0x4000 字节）

如所提供的大小大于 MJUM16BYTES，则会触发断言。遗憾的是，只有在使用 RT_STRICT 宏时该断言才会被编译，在发布build 中并非如此。这意味着触及该断言时执行将继续，从而导致分配选择的存储桶大小为0x800。由于实际大小更大，因此当用户数据拷贝到mbuf 报文时出现堆溢出问题。

CVE-2021-2310：Oracle VirtualBox NAT 堆缓冲区溢出提权漏洞

代码中存在一个名为 “PDMNetGsoIsValid” 的函数，用于验证guest 提供的 GSO 参数是否合法。然而，无论何时使用该函数，它都位于断言中。如：

如上所述，在发布build中并不会编译这类断言，从而允许出现不合法的GSO参数；slirp_ext_m_get的大小计算可能出错，使其小于for循环中 memcpy 复制的总大小。在我发布的PoC 中，cbMin 的 pGso->cbHdrsTotal + pGso->cbMaxSeg计算中所用的参数导致分配了0x4000字节，但cbPayload 的计算导致 memcpy 调用了0x4056大小，从而溢出了所分配的区域。

CVE-2021-2442：Oracle VirtualBox NAT UDP 标头界外溢出

这篇文章的标题中仅提到了“VirtualBox Network Offloads”，看似GSO是唯一易受影响的卸载机制；然而，另外一个卸载机制也易受攻击：校验和卸载(Checksum Offload)。

校验和卸载可应用于报文标头中存在校验和的多种协议中。在模拟时，TCP和UDP 协议中VirtualBox 均支持这一点。

为了访问该特性，GSO 框架需要设置 u8Flags 成员的第一个比特，说明要求校验和卸载。在 VirtualBox 案例中，必须设置该比特，因为它无法在不执行校验和卸载的情况下处理GSO。当 VirtualBox 以GSO处理UDP数据包时，在某些情况下会终于函数 PDMNetGsoCarveSegmentQD。

函数 pdmNetGsoUpdateUdpHdrUfo 使用 offHdr2 提示 UDP 标头在数据包结构中的未知。最终它将引向名为 “RTNetUDPChecksum” 的函数中：

而这正是存在漏洞的地方。在这个函数中，uh_ulen 属性完全是受信任的且无需任何内证，这就导致缓冲区的边界溢出或者因减去sizeof(*pUdpHdr) 而导致的整数下溢问题。

rtNetIPv4AddDataChecksum 同时接收大小值和数据包标头指针并继续计算校验和：

从利用角度看，将大量界外数据相加可能没有值得关注的点。然而，如果攻击者能够为连续的 UDP 数据包重新分配同样的堆位置，UDP大小参数一次增加两个字节，则可能计算出每个校验和中的差异并泄露界外数据。

同时，攻击者很可能利用该漏洞引起针对网络中其它虚拟机的拒绝服务攻击。

卸载支持在现代网络设备中很常见，因此它很自然地出现在了虚拟化软件模拟设备中。虽然多数公开研究专注于主流组件如环形缓冲区等，但卸载似乎并未得到足够的审视。遗憾的是，我未能在 Pwn2Own 大赛中及时获得exploit，因此只好将前两个漏洞报告给ZDI，将剩下的校验和漏洞直接提交给了Oracle 公司。