远程 OracleVM 系统缺少必要修补程序来解决关键安全更新：

- x86：修复页表 pin 错误路径中的页面引用计数处理 在处理 XSA-45 系列的原始修补程序 7 中，我错误地在 alloc_page_type 中添加了对 get_page_light 的调用以覆盖两个可能发生的减少情况：一种针对与调用一起设置的 PGT_partial 位，另一种针对引用调用程序保持的页面（会在其错误路径中丢弃）。但是当然会将其他页面引用绑定到 PGT_partial 位，因此将 ->arch.old_guest_table 保留为非空以用于清除错误的函数的任何调用程序需要确保保留相应的页面引用。此后在其他各处也发现了类似问题：实际上，get_page_type_preemptible 的所有调用程序都需要以类似方式处理错误。为确保按此方式运行错误处理并不会泄漏页面引用，已向该函数添加相应的断言。这是 CVE-2013-1432/XSA-58。

- libxl：限制有关 PV 控制台设备 xenstore 节点的权限 Matthew Daley 发现 PV 控制台协议将敏感的主机状态置于客户机可写入的 xenstore 位置，其中包括：

- pty 用于在控制台后端后台程序及其客户端之间通信，允许客户机管理员读取和写入任意主机文件。

- 输出文件，允许客户机管理员写入任意主机文件，或定位任意包含套接字、udp、ptr、管道等内容的 qemu chardev（有关更完整的列表，请参阅 qemu(1) 中的 -chardev）。

- 最大缓冲区大小，使客户机管理员可消耗比主机管理员配置的资源量更多的资源。

- 要使用的后端（qemu 与 xenconsoled）可能允许客户机管理员迷惑主机软件。因此将 xenstore 前端目录中的敏感键设为只能由访客进行读取。
 这样做是安全的，因为与 POSIX 目录权限不同，xenstore 权限模型不允许对包含的目录具有写入权限的访客删除和重新创建节点。有几个相关的小问题：

- 主 PV 控制台“很特殊”。它是 xenstore 节点但不在通常的 /devices/ 子树下，也不使用通常的 xenstore 状态机协议。
 而且，其目录还用于其他内容，包括 VNC 端口节点，而我们不希望客户机也能写入该节点。没有尝试跟踪该目录所有可能的次要使用，而是仅使其对客户机只读。所有新创建的子目录会继承这些权限，因此目前在默认情况下是安全的。

- 其他串行控制台使用通常的 xenstore状态机，因此至少需要“协议”和“状态”节点的写入权限，然而它们可能还想使用任意“feature-foo”节点（尽管并没有发现任何此类情况），因此我们无法直接锁定整个前端目录。相反，我们添加了对前端键的 libxl__device_generic_add 的支持，这些前端键明确为只读，并使用后者锁定敏感键。

- Minios 的控制台前端想要写入“类型”节点，但其无法实现该操作，因为这是主机/工具堆栈级决策。此操作将失败，因为该节点现在对 PV 客户机为只读。由于工具堆栈已写入该节点，所以只需删除设置它的尝试。这是 CVE-XXXX-XXX / XSA-57

冲突（4.2 向后移植）：tools/libxl/libxl.c（无 vtpm，libxl__device_console_add 中出错时释放 front_ro）冲突（4.1 向后移植）：extras/mini-os/console/xenbus.c tools/libxl/libxl.c tools/libxl/libxl_device.c tools/libxl/libxl_internal.h tools/libxl/libxl_pci.c tools/libxl/libxl_xshelp.c

- Minios 代码在 xencons_ring.c 中

- 许多地方需要 &gc 而不只是 gc

- libxl__xs_writev 路径不一致

- 多个次要上下文修正

检测

OracleVM 3.1：xen (OVMSA-2013-0057)

high Nessus 插件 ID 79513

未找到变更日志