Kernel Side-Channel Attacks - CVE-2017-5754 CVE-2017-5753 CVE-2017-5715

受影响的产品

红帽产品安全团队把此安全漏洞的严重性级别定为重要（Important）。

以下版本的红帽产品会受到影响：

• Red Hat Enterprise Linux 5

• Red Hat Enterprise Linux 6

• Red Hat Enterprise Linux 7

• Red Hat Atomic Host

• Red Hat Enterprise MRG 2

• Red Hat OpenShift Online v2

• Red Hat OpenShift Online v3

• Red Hat Virtualization (RHEV-H/RHV-H)

• Red Hat Enterprise Linux OpenStack Platform 6.0 (Juno)

• Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) for RHEL7

• Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) director for RHEL7

• Red Hat OpenStack Platform 8.0 (Liberty)

• Red Hat OpenStack Platform 8.0 (Liberty) director

• Red Hat OpenStack Platform 9.0 (Mitaka)

• Red Hat OpenStack Platform 9.0 (Mitaka) director

• Red Hat OpenStack Platform 10.0 (Newton)

• Red Hat OpenStack Platform 11.0 (Ocata)

• Red Hat OpenStack Platform 12.0 (Pike)

虽然红帽的 Linux Container 本身不会直接受到内核问题的影响，但它们的安全性需要依赖于主机内核环境的安全。红帽推荐使用最新版本的容器镜像。Container Health Index（Red Hat Container Catalog 的一部分）可以用来检查红帽容器的安全状态。为了保护所有容器的隐私，需要确保所使用的容器主机（例如，Red Hat Enterprise Linux 或 Atomic Host）已进行了可以解决这个安全问题的更新。红帽已发布了一个可以解决这个问题的 Atomic Host 更新版本。

安全攻击描述及影响

本文档中所描述的安全攻击滥用了现代高性能微处理器的“预测执行（speculative execution）”功能。这类微处理器包括一个被称为 “Out-of-Order（乱序）” (OoO) 执行的功能来优化系统性能，它们会在独立指令所依赖数据有效时就开始执行指令（被称为“data flow（数据流）”模式），而不是完全按照程序员在代码中所指定的顺序执行。它们会使用不同的内部重排序数据结构来对指令执行的状态进行缓冲处理，最终获得顺序的结果。Out of Order (OoO) 执行功能最初由 Robert Tomasulo 在 1967 发明，用于早期的 IBM 大型主机系统中。现在，这个功能几乎已成为所有微处理器的标准功能。

OoO 执行模式的扩展添加了一个高度精密的代码分支预测算法，它被用来预测一个特定的软件代码路径（分支）是否会被执行。一个分支可以被看作为处理器对执行指令流程的一种变化（对应于一个 “if” 指令，如 “if this, then do A, otherwise do B”）。其中是否执行某个分支的条件所依赖的数据可能不会马上获得（例如，需要从较慢的 RAM 加载到内部微处理器的缓存系统中）。因此，在分支条件所依赖的数据还无法获得时，处理器根据分支预测系统输入的信息，开始预测执行最可能会被执行的分支。运行的结果会以特定的方式保存，当以后发现预测执行的分支不应该被执行时，它们的结果会被丢弃。预测执行功能通常对于程序开发人员，以及同一个系统中的其它用户是完全不可见的。

这里所提到的安全攻击依赖微处理器进行预测执行时的内部状态来实现。特别地，这种安全攻击依赖于“cache side channel analysis” 的技术。在进行预测执行阶段，处理器不会允许程序员、其它处理器或其它运行的应用在内存或寄存器中获得中间的结果。但是，预测执行的代码执行过程中访问了内存，被访问的内存中的数据会载入到处理器的缓存中。而一个攻击者可以利用 side channel analysis 观测载入到处理器缓存中的数据以及载入到系统缓存中的数据，这些数据甚至是来自于不应该被执行的执行路径中的数据。一个精心设置的程序，可以把一个存在于需要权限的内存位置的数据，通过预测执行载入到处理器缓存中，并监视程序的运行情况，进而利用这些推断出需要权限的内存位置中的数据。

另一个触发 CPU 进行预测执行操作的情况是分支。攻击者可以开始“训练”分支预测系统，使它认为内核代码中的一个特定分支会被大量调用（或不被调用）。当分支下一次执行时，处理器将会根据攻击者设计的方向执行代码。如果执行的代码会从内存中加载一个值，则这个操作在预测执行时就可以被攻击者利用。通过分支预测进行的攻击会扩展到内核/hypervisor 的范围内，从而使一个没有权限的客户机操作系统影响到 hypervisor 的执行操作。再结合使用 side channel analysis，就可以获取 hypervisor 内存中的敏感数据。

另外，预测执行可能会影响到更广的范围。因为微处理器的内部状态对于程序员、其它用户以及系统上运行的其它应用是不可见的，所以处理器可能会在没有检查是否有相关权限的情况下，预测执行数据访问操作。权限检查会并行进行，最终会在决定放弃已预测执行的指令前，才触发一个终止预测执行的操作，这就使得那些预测执行的结果在处理器以外可见。如果处理器在完成权限检查前将内存中的数据载入到处理器缓存中，则就有可能在后续的内存访问中感知到这些数据。

这类权限检查的一个例子是内存管理单元（MMU）中的内存页访问检查。分页是高性能微处理器中的一个常见的功能，它使操作系统可以控制虚拟内存地址到物理内存地址的映射，同时通过访问控制位限制对虚拟地址的访问。例如，一个页可以被标记为 “read-only”，因此写操作会导致一个页失败异常；或标记为 “kernel memory”，因此 用户态权限的访问会导致一个页失败异常。

因为处理器的权限检查强制限制了用户态应用不能访问内核内存，所以业界的标准做法是，操作系统内核（包括 Linux）把内核虚拟内存地址映射到和用户态应用程序相同的地址空间中。这种做法可以大大提高性能，因为应用程序会频繁使用由内核提供的系统调用。如果每个系统调用都需要切换地址空间，则会产生大量性能负担，因为每次地址切换都需要刷新许多内部 CPU 数据结构，如 TLB(Translation Lookaside Buffers，用于缓存虚拟内存地址到物理内存地址的映射，并加快虚拟内存的使用速度）。

但是，内核和用户态应用程序间共享页表，使利用预测执行进行安全攻击成为可能。在这种情况下，攻击者可以骗取内核在处理器的 L1数据缓存中加载一个“有兴趣”的虚拟地址。L1 数据缓存通常是以一个名为 VIPT (Virtually Indexed, Physically Tagged) 的技术进行组织的，它使虚拟到物理地址翻译操作和权限检查操作并行进行。因为存在了共享的虚拟地址空间，在预测执行期间，一个不被信任的用户代码就有可能通过 预测执行访问到只有内核才有权限访问的虚拟地址并将其数据加载到L1缓存中，其中加载的数据可以在预测执行的路径的更深处使用。因此，接下来的一个预测执行时的内存访问可以根据前面那些需要权限的内存内容填充缓存，通过其结果就可以推断出前面那些需要权限才可以访问的内存数据。

这类微处理器的 side channel attack 可以让一个不被信任的用户，通过访问一个机器来获取其需要内核权限的敏感信息，或 hypervisor 的内存；同样，也可以获得在同一个系统上运行的其它应用程序或虚拟机的敏感信息。对于这类攻击的缓解方案通常会包括特定的步骤，并取决于微处理器的系列和型号，针对不同的变体采用不同的方案：

• 隔离内核态和用户态虚拟地址空间：这通过使用操作系统内核的 KPTI（Kernel Page Table Isolation）实现，它有时也被称为 “KAISER”。
• 禁用间接分支预测进入内核或 hypervisor：相关功能在业界已通过 microcode、millicode、firmware，以及其它更新的方式加入到微处理器中。更新的 Red Hat Enterprise Linux 可以控制对这些功能的使用。
• 隔离预测加载特定的内存位置：这需要对内核进行小的改变，红帽更新已集成了相应的内核改变。

通过这些软件解决方案，以及 microcode、millicode 和 firmware 的更新，可以缓解这里介绍的安全攻击。但是，会对系统性能造成一些影响。这取决于具体系统、以及微处理器的型号和业务特性，对系统性能造成的影响可能会较大。对于安全性问题，红帽会采取主动的方式，把系统安全放到比性能更高的地位。同时，用户可以获得更高的灵活性，根据自己的具体情况，在安全性和性能间进行平衡，选择适当的修复方式。

当前针对这个安全问题的更新会对系统性能有一定影响，具体的影响程度取决于 CPU 的系列、版本，以及应用程序。红帽的性能工程团队创建了一个 Knowledgebase article，介绍了对一系列典型工作负载所产生的性能影响，以及用户可以根据自己的具体情况，通过禁用一些安全修复选项来降低对性能影响的可能。随着这个安全问题的发展，我们会及时发布新的相关信息。

红帽性能工程团队和产品工程团队编写了一个 Knowledgebase article，它详细介绍了可以用来禁用或使用这些新安全性能的 tunables。

使用基于 AMD 的系统的订阅用户可以参阅这个 Knowledgebase article 来获得额外的信息。

检测和诊断

检查您的系统是否存在安全漏洞

红帽已创建了一个 Labs 应用以帮助用户检测受这些安全漏洞影响的环境。具有有效订阅的用户可以使用以下链接访问 Labs 工具。

检查您的系统是否存在安全漏洞。使用这里提供的检测脚本检查您的系统是否会受到这个安全漏洞的影响。您可以下载附带的 GPG 签名来验证脚本的真实性。这个脚本当前的版本是 2.4。

具有相关订阅的、运行 Red Hat Virtualization 产品的用户，可以参照 Knowledgebase article 来验证 OEM 提供的 microcode/firmware。

采取行动

我们强烈建议，所有运行受影响版本的红帽产品的用户，在相关勘误可用后尽快进行更新。用户需要尽快对环境进行相关的更新。所有受影响的产品都应该进行针对所有 3 个变体进行更新： CVE-2017-5753 (变体 1)、 CVE-2017-5715 (变体 2) 和 CVE-2017-5754 (变体 3）。

注释

• Meltdown 是 CVE-2017-5754 (变体 3) 的名称
• Spectre 是 CVE-2017-5753 (变体 1) 和 CVE-2017-5715 (变体 2) 组合的名称
• 因为所需要的改变，运行Red Hat Enterprise Linux 7.2 或更高版本用户的 kpatch 将不会提供。
• 变体 2 可以通过本地（在同一个操作系统中），或通过虚拟环境中的客户机实现。相关的修正需要更新 CPU 的 microcode/firmware。我们建议订阅用户联系相关的硬件 OEM 来获得相关的 microcode/firmware。另外，我们创建了一个 Knowledgebase article 详细介绍了相关信息。
• 请仔细阅读安全勘误的内容。在初始发行中，不是所有的架构都有缓解方案。x86_64 缓解方案不包括 Red Hat Enterprise Linux 6 32bit 内核。
• 使用 Red Hat OpenStack Platform 的用户，请参阅相关的 Knowledgebase article。
• 使用 Red Hat Satellite 6 的用户，请参阅相关的 Satellite 6 Knowledgebase article。请使用以下表格查找您需要应用到您系统的 RHSA ID。

受影响产品的更新

* 为了获得这个补丁程序，需要一个有效的 ELS 订阅。如果您的账户不包括有效的 ELS 订阅，请联系红帽的销售人员，或您专门的销售代表。

* 为了获得这个补丁程序，需要一个有效的 EUS 订阅。如果您的账户不包括有效的 EUS 订阅，请联系红帽的销售人员，或您专门的销售代表。

什么是 Red Hat Enterprise Linux Extended Update Support 订阅？

***需要有效的 AUS 订阅才可获得在 RHEL AUS 中的这个补丁。

什么是 Advanced mission critical Update Support (AUS)?

****需要有效的 TUS 订阅才可获得在 RHEL TUS 中的这个补丁。

***** 订阅用户应该联系硬件 OEM 来获得最新版本的 CPU 微码/固件。

补救方法

除了应用相关厂商的软件更新以及硬件 OEM 的 CPU microcode/fiirmware，当前没有其它补救方法。所有红帽用户需要在相关更新可用时，根据厂商提供的解决方案对 CPU 应用补丁，更新内核以及相关的软件包。

我们建议用户使用基于风险程度的方法对这个问题进行补救。那些需要高安全性、高度信任的系统应该首先进行处理，并应该在可以对它们进行处理前，把它们和不被信任的系统隔离来，以减少这个安全漏洞可能造成的安全风险。

运行 XEN hypervisor 的用户应该了解，软件本身的技术局限性限制了完全解决变体 2 问题的可能，也限制了在一个准虚拟化的客户机上完全解决变体 3 的可能。红帽已创建了一个 Knowledgebase article 文档详细介绍了 XEN 的解决方案，以及 XEN-hypervisor 用户可以选择的选项。