跳转到: 导航, 搜索

OSSN/OSSN-0028


Nova 将计算节点 SMBIOS 序列号泄露给虚拟机

总结

当 Nova 使用 libvirt 虚拟化驱动时,libvirt 提供的 SMBIOS 序列号会被提供给在计算节点上运行的虚拟机实例。该序列号可能会暴露关于底层计算节点硬件的敏感信息。

受影响的服务 / 软件

Nova, Icehouse, Havana

讨论

虚拟机 SMBIOS 表中的“serial”字段基于 libvirt 报告的主机硬件 UUID 填充。其目的是允许关联在同一主机上运行的虚拟机。

不幸的是,一些硬件厂商使用主机 UUID 的子集作为检索硬件支持合同信息的密钥,而无需任何身份验证。在这种情况下,将主机 UUID 暴露给虚拟机对于这些厂商来说是一种信息泄露。

理论上,云用户可以通过启动大量短生命周期虚拟机,利用暴露的主机 UUID 来大致估计云中可用的唯一主机数量。

建议的操作

可以通过在 /etc/libvirt/libvirtd.conf 中设置 'host_uuid' 参数来覆盖 libvirt 中计算节点 SMBIOS 数据的用途。这允许设置一个用于标识目的的任意 UUID,而不会泄露关于实际底层硬件的任何信息。建议利用此覆盖功能,以防止潜在地暴露关于底层计算节点硬件的信息。

在 OpenStack 的 Juno 版本中,Nova 的 libvirt 驱动程序允许通过新的 'sysinfo_serial' 配置参数来控制主机 UUID 的来源。这个新参数允许以下值:

  • 'auto' - 尝试 /etc/machine-id,回退到 libvirt 报告的主机 UUID(新的默认值)
  • 'hardware' - 始终使用 libvirt 主机 UUID(旧的默认值)
  • 'os' - 始终使用 /etc/machine-id,如果文件缺失则报错
  • 'none' - 不向虚拟机报告任何值


通常,最好使用 /etc/machine-id UUID 而不是主机硬件 UUID。后者是 systemd 引入的 Linux 发行版的最新标准,用于提供每个操作系统安装的唯一 UUID。这意味着即使容器也会看到单独的 /etc/machine-id 值。预计该 /etc/machine-id 在当前和未来的发行版中将广泛可用。如果此文件缺失,仍然可以回退到 libvirt 报告的主机 UUID。

担心暴露识别底层计算节点能力的管理人员可能希望通过使用“none”值完全禁用任何 sysinfo 序列号字段的报告。

联系方式 / 参考文献