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 序列号字段的报告。
联系方式 / 参考文献
- 作者:Nathan Kinder, Red Hat
- 此 OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0028
- 原始 LaunchPad Bug: https://bugs.launchpad.net/nova/+bug/1337349
- OpenStack Security ML:openstack-security@lists.openstack.org
- OpenStack Security Group:https://launchpad.net/~openstack-ossg