前言

Security Recommendations for Server-based Hypervisor Platforms（NIST.SP.800-125A）[1]，直译为“针对基于服务器的Hypervisor平台的安全建议”，是由Ramaswamy Chandramouli编写的一份标准，其修订版（即NIST.SP.800-125Ar1）于2018年6月发布。

作者Ramaswamy Chandramouli来自NIST的信息技术实验室-计算机安全部门-安全系统和应用程序组[3]，编写了多份信息安全相关标准[2]，包括NIST.SP.800-125A的姊妹篇NIST.SP.800-125B——Secure Virtual Network Configuration for Virtual Machine Protection [4]，直译为“虚拟机保护的安全网络配置”。

NIST.SP.800-125Ar1首先从“基线功能”（Baseline Functions）对Hypervisor进行了抽象定义，接着分析了Hypervisor平台可能的威胁来源，并进一步得出不同Hypervisor基线功能面临的针对性威胁，最后给出了全面的安全建议。

对于从事虚拟化安全研究的同学来说，该文档是一份非常好的指南。本文将对这份文档的内容进行总结提炼，附加一些笔者个人的思考和拓展延伸的知识。

注意：

  1. 本文不再翻译Hypervisor，而是直接使用该单词。仅在此处面向好奇的读者作以下解释：Hypervisor通常指用于管理虚拟机的软件集合，在一些资料中等同于“虚拟机管理器”（Virtual Machine Manager，简称VMM）。
  2. NIST.SP.800-125Ar1没有对虚拟化网络安全做过多讲解，相关内容可以参考NIST.SP.800-125B。
  3. 除非有特殊说明，NIST.SP.800-125Ar1不区分I型虚拟化和II型虚拟化，也不区分全虚拟化和半虚拟化，其分析对所有类型的Hypervisor均适用。

2022-05-14更新

其实NIST于2011年出了一份800-125 [8]，大概读了一下，收获没有800-125Ar1大。就虚拟化安全而言，800-125主要分析了虚拟机隔离性、虚拟机监控、镜像和快照的管理三大方面，在800-125Ar1中都有覆盖到。除此之外，800-125从Hypervisor安全、虚拟机安全、虚拟化基础设施安全和桌面虚拟化安全四个方面给了一些建议。最后，给了执行计划和落地步骤。总体而言，800-125尚可，毕竟是十几年前的文档。不过相比之下，还是直接读800-125Ar1即可。

2022-05-15更新

NIST.SP.800-125B内容不多，不值得单独开一篇笔记，附在这里吧。主要介绍了虚拟机网络分段、虚拟机网络冗余、基于防火墙的虚拟机流量控制和虚拟机流量监控：

  1. 网络分段：
    1. 分离宿主机
    2. 使用虚拟交换机
    3. 使用虚拟防火墙
    4. 使用VLAN
    5. 使用Overlay虚拟网络
  2. 网络冗余（基于NIC Teaming（网卡绑定）的网络冗余）
  3. 基于防火墙的虚拟机流量控制：
    1. 使用物理防火墙
    2. 使用子网级别的虚拟防火墙
    3. 使用基于内核的虚拟防火墙
  4. 虚拟机流量监控（基于port mirroring）：
    1. 通过配置虚拟机网络适配器来启用虚拟机流量监控
    2. 通过配置虚拟交换机端口来启用虚拟机流量监控

术语定义

前面已经提到，NIST.SP.800-125Ar1的核心内容由四部分组成：基础功能、威胁来源、潜在威胁和安全建议。为了实现规范化和量化描述，作者定义了五个术语：

  • HY-BF：Hypervisor Baseline Function的缩写，指Hypervisor应该具备的基础功能。
  • HY-TS：Hypervisor Threat Source的缩写，指Hypervisor面临的潜在威胁的来源。
  • HYP-T：Hypervisor Threat的缩写，指Hypervisor面临的潜在威胁。
  • HY-DV：Hypervisor Design Vulnerability的缩写，指Hypervisor存在的潜在设计漏洞。
  • HY-SR：Hypervisor Security Recommendation的缩写，指针对Hypervisor的安全建议。

明确了以上术语后，我们可以做如下总结：作者在NIST.SP.800-125Ar1中介绍了5个HY-BF、3个HY-TS、3个HYP-T、5个HY-DV和20个HY-SR。

然而，这五大要素之间的关系并非平坦简单的，而是有从属和交错，且听笔者一一道来。

注：作者有时会将HY-DV写作HYP-DV，本文中统一写作HY-DV。

信任模型

在展开分析之前，NIST.SP.800-125Ar1对Hypervisor平台的信任模型进行了定义。在一个Hypervisor平台中：

  1. 虚拟机是不可信的，包括虚拟机操作系统和所有用户态应用程序。
  2. Hypervisor平台中的设备驱动是不可信的，除非它们带有安全证书。
  3. 提供虚拟机隔离的Hypervisor核心组件是可信的。
  4. 对于II型Hypervisor来说，宿主机操作系统是可信的。
  5. Hypervisor宿主的硬件是可信的。

然而，作者也提到，宿主机硬件其实并非完全可信。一些侧信道攻击可能会影响到共享的硬件资源，例如，Spectre和Meltdown两个CPU级别的漏洞[5]可能会导致敏感信息泄露。

诚然，从Hypervisor安全的角度去考虑时，作者上述模型定义无可厚非。然而，如果从全局视角来看，信任模型是相对的。更准确地说，信任模型应该建立在责任共担模型基础上。就云计算环境下的两大角色——云计算服务提供商（Cloud Service Provider，简称CSP）和用户来说，信任模型让两者对立，责任共担模型则让两者约定和协商。如此而言，责任共担模型的不同场景应该对应不同的信任模型。信任和安全，完全要看谁负责和对谁而言。宿主环境是否可信的问题和对此的需求也衍生出了可信计算、机密计算等技术。

总而言之，在NIST.SP.800-125Ar1的主题范围下，以上信任模型没有问题，但是我们也要认识到，信任是相对的。

五个基础功能

根据NIST.SP.800-125Ar1，Hypervisor的五个基础功能如下：

  1. 虚拟机进程隔离（HY-BF1）：实现虚拟机调度，虚拟机内进程的CPU、内存管理，多处理器间上下文切换等功能；管理支持直接内存访问（DMA）的设备。
  2. 设备调解和访问控制（HY-BF2）：管理虚拟机对设备的访问。
  3. 虚拟机命令的直接执行（HY-BF3）：直接执行来自虚拟机的命令（适用于半虚拟化）。
  4. 虚拟机生命周期管理（HY-BF4）：包括虚拟机镜像的创建和管理、虚拟机状态控制、虚拟机迁移和快照、虚拟机监视和策略实施等。
  5. Hypervisor平台管理（HY-BF5）：包括资产定义、Hypervisor软件模块的配置项设置和模块更新等。

提出安全建议的思路

保护Hypervisor安全，从信息安全三要素的角度来讲就是保护Hypervisor功能的机密性、完整性和可用性。基于此，作者提出安全建议的思路如下：

  1. 确保Hypervisor平台所有组件的完整性。
  2. 识别Hypervisor平台的威胁来源。
  3. 对于Hypervisor的五个基础功能，识别每个功能下的任务和这些任务面临的威胁，进而给出应对措施。

三个威胁来源

根据NIST.SP.800-125Ar1，Hypervisor的三个威胁来源如下：

  1. 来自Hypervisor宿主机所在企业网络（HY-TS1）。
  2. 来自恶意或被攻陷的虚拟机（HY-TS2）：威胁传播通道可能是共享的Hypervisor内存或Hypervisor建立的内部网络。
  3. 来自虚拟机Web管理端和管理控制台（HY-TS3）。

作者认为，HY-TS1和HY-TS3在传统服务器环境中已经存在，HY-TS2是虚拟化环境独有的。

其实，上述威胁来源分析结果和以容器和Kubernetes为基础的云原生环境十分类似。然而，虽然HY-TS3在传统服务器环境中也存在，但是近年来虚拟机Web管理端多次曝出重大安全漏洞（如VMware VCenter的CVE-2021-21985 [6]和CVE-2021-21972 [7]），十分值得研究人员重视。

来自HY-TS2的三个潜在威胁

这里提到的三个潜在威胁，指的是来自HY-TS2的威胁，也就是恶意或被攻陷的虚拟机可能对Hypervisor产生的威胁，它们分别是：

  1. 进程隔离性的破坏——虚拟机逃逸（HYP-T1）：这是Hypervisor面临的主要威胁，也是虚拟化安全研究的重点和热点。其潜在原因有两个：
    1. Hypervisor设计漏洞。
    2. 恶意或脆弱的设备驱动。
  2. 网络隔离性的破坏（HYP-T2）：如IP、MAC伪造、通信劫持等，通常针对虚拟机所在的虚拟化网络段。
  3. 拒绝服务（HYP-T3）：错误配置的或恶意虚拟机可能会导致宿主机资源的大量消耗，导致其他虚拟机或宿主机拒绝服务。

五个潜在设计漏洞

前文我们提到，针对Hypervisor虚拟机进程隔离功能（HY-BF1）的主要威胁是进程隔离性的破坏（HYP-T1），原因之一是Hypervisor设计上可能存在的潜在漏洞。因此，本节列出的五个潜在设计漏洞均指的是可能导致HYP-T1威胁的漏洞。另外，这五处是推理分析的结果，并不是说一定有实际的漏洞存在（事实上，确实有不少相关的CVE漏洞存在）。

事实上，在NIST.SP.800-125Ar1中，前四个设计漏洞被列在“针对HY-BF1的潜在威胁”部分，第五个则被列在“针对HY-BF2的潜在威胁”部分。为了方便大家从整体上把握NIST.SP.800-125Ar1的精髓，我们把这五个设计漏洞单独提炼出来形成本节。这说明不同基础功能及威胁之间并非完全割裂，也是我们前面说五大基础功能之间的关系并非平坦简单的缘由。

  1. 虚拟机控制结构VMCS（HY-DV1）：用来存储虚拟机状态的数据结构，VMCS的潜在问题可能会导致Hypervisor内存泄露。
  2. 敏感指令处理（HY-DV2）：如果未能正确捕获、处理虚拟机发出的特权指令，它们就有可能被直接执行。
  3. 内存管理单元MMU（HY-DV3）：Hypervisor的软件实现的MMU为虚拟机分配影子页表，避免虚拟机直接访问硬件MMU。该软件MMU的潜在问题可能会导致任意地址空间数据泄露。
  4. I/O内存管理单元IOMMU（HY-DV4）：Hypervisor借助硬件IOMMU来约束进行直接“内存访问”（DMA）的设备驱动和进程。如果缺乏这一管控，虚拟机可能会通过DMA来修改物理内存（常见的攻击向量）。
  5. 支持DMA的硬件设备（HY-DV5）：对于支持DMA的硬件设备来说，由于虚拟机能够控制设备，它能够通过对设备编程实现在宿主机物理内存上执行DMA操作（这样一来，通过HY-BF1中MMU实现的隔离管控功能也失去作用了）。

下一节将按照基础功能划分依次介绍不同基础功能面临的潜在威胁，其中会包含五个潜在设计漏洞的内容。

五个基础功能面临的不同威胁

HY-BF1（虚拟机进程隔离）功能面临的潜在威胁

针对Hypervisor虚拟机进程隔离功能（HY-BF1）的主要威胁是进程隔离性的破坏（HYP-T1），上一节已经对相关的设计漏洞进行说明，此处不再赘述。

HY-BF2（设备调解和访问控制）功能面临的潜在威胁

设备虚拟化的三种常见方式为：

  1. 模拟（Emulation）
  2. 半虚拟化（Para-virtualization）
  3. 设备透传（Passthrough）或自虚拟化（Self-Virtualizing）

其中，半虚拟化面临的威胁将在下一节（HY-BF3）的威胁分析中进行讲述；设备透传涉及到的DMA则可能导致HY-BF1的破坏，在上一节也已经分析过。

HY-BF3（虚拟机命令的直接执行）功能面临的潜在威胁

HY-BF3适用于半虚拟化。这里的问题是，如果缺乏对来自虚拟机指令的有效验证，这些指令可能直接被宿主机执行。这进而又会导致HY-BF1的破坏。

HY-BF4（虚拟机生命周期管理）功能面临的潜在威胁

HY-BF4面临的威胁主要有两个：

  1. 镜像库中的非标准虚拟机镜像可能使用的是未及时更新的操作系统，从而引入HYP-T1到HYP-T3等威胁。
  2. 由非标准镜像或快照启动的虚拟机实例可能引入HYP-T1到HYP-T3等威胁。

初看起来，上述两点似乎能够合并为一点，但是从虚拟机生命周期管理的角度来看，它们确实是不同的阶段。

HY-BF5（Hypervisor平台管理）功能面临的潜在威胁

HY-BF5涉及的威胁基本等同于传统环境下的远程管理面临的威胁，因此NIST.SP.800-125Ar1不再展开讲述。

二十个安全建议

针对前述威胁，NIST.SP.800-125Ar1共提出了二十个安全建议，分别是：

  1. （平台完整性）Hypervisor应在具有以下功能的平台和基础设施上启动（HY-SR1）：
    1. 硬件支持“度量过的启动环境”（Measured Launch Environment，MLE）。
    2. 有能力进行从硬件到所有Hypervisor组件的信任链验证。
  2. （针对HY-BF1）宿主机硬件应辅助进行指令集虚拟化和基于MMU的内存管理（HY-SR2）。
  3. （针对HY-BF1）Hypervisor应通过配置项支持为每个需要物理内存的虚拟机进行物理内存分配和限制（HY-SR3）。
  4. （针对HY-BF1）Hypervisor应提供强力配置项确保虚拟机不能使用超限CPU资源（HY-SR4）。
  5. （针对HY-BF1）Hypervisor应提供设定虚拟机的CPU时钟周期上下限和调度优先级的功能（HY-SR5）。
  6. （针对HY-BF2）根据设备虚拟化的不同实现，本条建议分为三个子项：
    1. 针对模拟方式：考虑到性能问题，应仅在复杂度可控的情况下使用设备模拟，如USB宿主控制器（HY-SR6A）。
    2. 针对半虚拟化方式：在这种情况下，对物理设备的访问管控应通过在专用虚拟机内（而非在Hypervisor中）运行后端设备驱动的方式实现，从而使后端设备驱动的权限低于Hypervisor；Hypervisor平台应包括以IOMMU形式提供的硬件支持，验证和翻译来自驱动域内硬件设备对宿主机内存的访问；IOMMU需支持DMA重映射功能，从设备发出到虚拟机物理地址（Guest Physical Address，GPA）的DMA请求必须先被翻译到宿主机物理地址（Host Physical Address，HPA）及检查是否落在该设备关联的保护域（HY-SR6B）。
    3. 针对设备透传或自虚拟化方式：在授予虚拟机直接访问DMA设备的情况下，Hypervisor平台应包括以IOMMU形式提供的硬件支持，验证和翻译所有针对宿主机内存的设备访问，本建议对自虚拟化硬件设备（基于SR-IOV标准）也适用；IOMMU需支持DMA重映射功能，从设备发出到GPA的DMA请求必须先被翻译到HPA及检查是否落在该设备关联的保护域（HY-SR6C）。
  7. （针对HY-BF2）就设备访问而言，需要设置访问控制列表（Access Control List，ACL）来限制虚拟机进程只能访问分配给该虚拟机的设备。对此，Hypervisor应支持标记虚拟机，或对每个虚拟机设定白名单、允许的设备名单（HY-SR7）。
  8. （针对HY-BF2）就设备使用而言，应为每台虚拟机设定网络和I/O带宽限制，以防止拒绝服务攻击（HY-SR8）。
  9. （针对HY-BF4）应为所有类型的虚拟机设置黄金标准（Gold Standard），不符合标准的虚拟机镜像不能被存储在虚拟机镜像服务器或仓库中；应定期扫描虚拟机镜像库中的镜像，及时发现旧版本和未打补丁的操作系统（HY-SR9）。
  10. （针对HY-BF4）（HY-SR10）镜像服务器中的每一个虚拟机镜像都应具有强有效的数字签名，用于可靠性和完整性检查。
  11. （针对HY-BF4）镜像仓库中虚拟机镜像的检入检出操作应受到可靠的访问控制机制约束，由被授权的管理员执行。在缺乏访问控制机制时，应将虚拟机镜像文件存储在加密设备上，仅能由少部分被授权的持有高强度口令的管理员操作（HY-SR11）。
  12. （针对HY-BF4）应采用安全协议（如TLS）访问虚拟机镜像存储服务器（HY-SR12）。
  13. （针对HY-BF4）应采用安全认证协议进行虚拟机热迁移；执行迁移的管理员的凭证应只发送给目的宿主机；内存内容和处理器数据应通过安全网络连接进行迁移；迁移应在专用虚拟机网络段进行（HY-SR13）。
  14. （针对HY-BF4）应有专门机制保证虚拟机操作的安全监控、安全策略实施、检测虚拟机内部的恶意进程（HY-SR14）。
  15. （针对HY-BF4）安全监控和安全策略实施机制应该在虚拟机外运行，利用Hypervisor的虚拟机自省（Introspection）能力。安全方案可以作为一个安全虚拟装置（Security Virtual Appliance，SVA）运行在一个单独的安全加固、可信的虚拟机内（HY-SR15）。
  16. （针对HY-BF4）所有反恶意软件工具应能够定期更新特征或样本库（HY-SR16）。
  17. （针对HY-BF4）虚拟机配置管理工具应能够生成日志，在虚拟机配置发生变化时向管理员发出告警（HY-SR17）。
  18. （针对HY-BF4）虚拟机管理的访问控制机制应在权限授予和对象上具备细粒度控制能力。另外，还应具备拒绝访问特定虚拟机组的控制能力（HY-SR18）。
  19. （针对HY-BF5）企业内部所有Hypervisor应采用企业虚拟化管理系统（Enterprise Virtualization Management System，EVMS）统一安装管理；企业中不同类型工作负载和集群适用的Hypervisor黄金标准配置应通过EVMS约束（HY-SR19）。
  20. （针对HY-BF5）Hypervisor宿主机保护和软件管理功能应通过专门分配的物理NIC保证。如果条件无法满足，至少将Hypervisor的管理接口放在专用虚拟网络段中，并使用防火墙进行访问控制（HY-SR20）。

总结

总体而言，NIST.SP.800-125Ar1对Hypervisor的基础功能、威胁来源、潜在威胁进行了比较清晰充分的分析，给出了可落地的安全建议，为后续的虚拟化安全研究指明了方向。

接下来，我们将从攻防两个角度，展开虚拟化安全研究。后续研究实质上是在将NIST.SP.800-125Ar1中提到的点进行发散扩展和落地。

参考文献

  1. NIST.SP.800-125Ar1 Security Recommendations for Server-based Hypervisor Platforms]
  2. https://www.nist.gov/people/ramaswamy-chandramouli
  3. https://www.nist.gov/itl/csd/secure-systems-and-applications
  4. NIST.SP.800-125B Secure Virtual Network Configuration for Virtual Machine (VM) Protection
  5. https://meltdownattack.com
  6. https://nvd.nist.gov/vuln/detail/CVE-2021-21985
  7. https://nvd.nist.gov/vuln/detail/CVE-2021-21972