Boot Hole 安全漏洞 - GRUB 2 boot loader - CVE-2020-10713

摘要

红帽目前正在解决 GRUB 2 引导加载程序（boot loader）中的一个缺陷，该缺陷会影响我们的产品，包括 Red Hat Enterprise Linux.通过利用这个缺陷，一个已在系统上的攻击者能够劫持引导过程，并在系统启动期间执行恶意代码。另外，也可以使用此漏洞绕过 UEFI 安全启动（Secure Boot）机制对系统的保护。（正常情况下，UEFI 安全启动机制会验证用于启动计算机的软件以达到保护系统的目的）。该问题已被编号为 CVE-2020-10713，严重性等级为Moderate（中度）。我们建议使用受影响版本的红帽客户应用相应的更新。红帽还建议更新到最新的镜像，并把运行容器的主机更新到最新版本。

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

• Red Hat Enterprise Linux 7

• Red Hat Enterprise Linux 8

• Red Hat Atomic Host 

• OpenShift Container Platform 4（RHEL CoreOS）。

请参照下面的诊断部分的内容，检查您的系统当前是否存在这些安全漏洞。此外，用户还可以使用下面提供的一个可以自动修复这些问题的 Ansible playbook

技术概述

通过 CVE-2020-10713，攻击者可以使用 GRUB 2 中的漏洞劫持并篡改 GRUB 的验证过程。利用此安全漏洞，还可以绕过安全引导（Secure Boot）机制对系统的保护。为了可以加载不受信任或已修改的内核，攻击者首先需要建立对系统的访问权限。例如，具有对系统的物理访问权限、具有修改通过 PXE 引导的网络的权限，或具有以 root 用户身份远程访问网络系统的权限。在获得了这类访问权限后，攻击者便可以通过注入恶意代码造成缓冲区溢出的问题，进而可以在 GRUB 中执行任意代码。 

为了确保对加载的内核进行安全引导保护，并防止系统在启动时加载不受信任的代码，现在为 grub2，内核，fwupdate，fwupd，shim 和 dbxtool 软件包颁发了新验证的密钥和证书。

缓解措施

当前没有对这个安全漏洞的缓解措施。 

补救方案

红帽建议所有客户更新 grub2 软件包。使用安全引导机制的红帽客户需要更新包含新验证的密钥和证书的内核、fwupdate、fwupd、shim 和 dbxtool 软件包。

在应用了 grub2 软件包更新后，运行带有安全引导机制的 Red Hat Enterprise Linux 8 的用户，需要采取额外步骤将系统启动到以前发行的 RHEL 8 内核。有关更多详细信息，请参见下面的 RHEL 8 部分。

技术细节

GRUB 2 引导加载程序可以通过 grub.cfg 文件进行配置。这个文件中包括了多个字符串令牌。在 GRUB 的初始化阶段，这个配置文件会在初始引导加载程序（称为 shim）加载它后被解析。在解析阶段，配置的值会被复制到保存在内存中的内部缓冲区中。如果其中的配置令牌的长度超过内部缓冲区大小，则会导致缓冲区溢出问题。攻击者可以利用此缺陷来执行任意代码，从而进一步劫持计算机的引导过程并绕过安全引导保护机制。因此，就有可能会加载未经过签名的二进制代码，从而进一步危害系统的安全性。

背景信息

什么是 UEFI 安全引导及其运作方式？

安全引导（Secure Boot）是由 UEFI 联盟开发的 UEFI 固件安全功能，它可以确保在启动期间仅加载不可变且经过签名的软件。安全引导使用加密技术和数字签名来验证所加载代码的真实性、来源和完整性。采取这些验证步骤是为了防止恶意代码被加载，并防止系统受到安全攻击，例如安装某些类型的 rootkits。有关 UEFI 和安全引导的详细信息，请参阅现代计算机安全解决方案中的 UEFI 安全引导。 

受信任的应用程序由中央证书颁发机构（CA）签名。公用证书存储在硬件中，从而使该证书签名的第三方 EFI 应用程序能够成功加载。

在支持安全引导机制的 Red Hat Enterprise Linux 版本中，经过签名并受信任的应用程序是 shim 软件包，它是机器固件加载的第一个应用程序。shim 软件包本身包括了红帽的证书，以及其自己的允许加载的受信任密钥和代码哈希的数据库。此数据用于验证引导加载程序签名，即GRUB 2，确保它没有被破坏或篡改。验证成功后，GRUB 会被加载并验证内核签名，确认它与红帽的证书或用户自己注册到 Allow DB 中的哈希值匹配。如果存在匹配项，则 GRUB 将加载内核，从而完成引导加载过程。

产品影响

Red Hat Enterprise Linux (RHEL) 7 和 8、Red Hat Enterprise Atomic Host，以及 RHEL CoreOS（Openshift Container Platform 4 的一部份）都带有存在安全漏洞的 GRUB 2 版本。 

Red Hat Enterprise Linux 8

由于在这些更新中包括了对内核的强化功能，以前的 Red Hat Enterprise Linux 8 内核版本尚未添加到 shim 的允许列表中。如果您运行的系统启用了安全引导机制，并且用户需要启动到较早的内核版本，则必须手动将其哈希值注册到信任列表中。这可以通过执行以下命令来实现：

# pesign -P -h -i /boot/vmlinuz-<version>

# mokutil --import-hash <hash value returned from pesign>

# reboot

Red Hat Enterprise Linux 7

红帽已将以前的 Red Hat Enterprise Linux 7 kernel 内核哈希值添加到了 shim 的 allow 数据库中，使用安全引导的用户可以启动到较早版本的内核中。 

RHEL Atomic Host

目前，无法在 RHEL Atomic Host 上更新 shim 二进制文件。客户应评估此问题，并决定是否需要使用更新的引导介质来置备节点。

OpenShift Container Platform 4（RHEL CoreOS）。

目前，红帽尚未发布用于 RHEL CoreOS 的 EFI 系统分区（包括 shim 和 grub）的更新。公认的最佳实践是定期重新置备节点；客户可以使用更新的“引导镜像”来这样做。 客户应评估此问题，并决定现在是否需要使用更新的引导镜像来置备节点

由于该漏洞主要影响启用了安全引导机制的裸机系统，因此更新和使用新的引导镜像只是一个推荐的操作。更新引导镜像的步骤可能会各不相同，这取决于客户如何置备其裸机基础架构。此过程可能需要更新引导基础结构的 PXE 配置，以提供新的引导镜像；或者可能涉及使用更新的安装 ISO 和裸机磁盘镜像重新安装裸机系统。客户应考虑其具体的环境，并参考 OpenShift 文档以了解如何正确更新引导镜像。有关更多信息，请参阅在裸机上安装集群。 

如果需要使用更新的引导镜像来重新置备节点，则客户应采取必要的步骤来处理（进行 cordon 和 drain 操作）需要重新置备的节点。客户应在适当的时间来重新置备节点，以避免破坏集群的整体健康状况。

对节点进行 cordon 操作：

$ oc adm cordon <node name>

对节点进行 drain 操作：

$ oc adm drain <node name>

当对节点的 cordon 和 drain 成功完成后，客户应重新引导并重新安装节点，然后确认已使用更新后的引导镜像正确地为其进行了重新置备。

受影响产品的更新

最初发布的 shim 软件包已被一个新版本取代。这个新版本的 shim 软件包已提供，可以将它与以前发布的 grub2、fwupd 和 fwupdate 软件包一起使用。如需了解与最初发布的 shim 软件包相关的信息，请参阅 https://access.redhat.com/solutions/5272311。 红帽强烈建议运行受影响版本的客户应用可用的更新。

¹ 什么是 Red Hat Enterprise Linux Extended Update Support (EUS) Subscription?

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

³ 什么是 Red Hat Enterprise Linux SAP Solutions 订阅?

⁴ Atomic Host

⁵ 公告/更新链接将在更新发布后添加。

⁶ 最初发布的 shim 软件包已被一个新版本取代。这个新版本的 shim 软件包已提供，可以将它与以前发布的 grub2、fwupd 和 fwupdate 软件包一起使用。如需了解与最初发布的 shim 软件包相关的信息，请参阅 https://access.redhat.com/solutions/5272311。

⁷ 为 RHEL 8 发布了更新的 dbxtool 软件包，以解决功能中的已知错误。可在以下文章中找到有关应用 DBX 更新的说明 - How to update the Secure Boot Forbidden Signature Database (DBX) with the latest UEFI Revocation List file

诊断

漏洞检测脚本适用于当前支持的 Red Hat Enterprise Linux 版本。检测脚本还可以用于 Red Hat Enterprise Linux 上的层次产品。

Ansible Playbook

以下提供了一个 Ansible playbook：CVE-2020-10713-update_fixit.yml。这个 Ansible playbook 更新所有相关的软件包。要使用这个 playbook，使用 HOSTS 变量指定要更新的主机：

ansible-playbook -e HOSTS=<myhosts> CVE-2020-10713-update_fixit--2020-07-29-1613.yml

您可以下载 OpenPGP 签名来验证脚本的真实性。

常问问题解答

问：如何检查我的系统是否启用了安全引导机制？

答：可以通过运行以下命令来检查是否启用了安全引导机制：

    $ mokutil --sb-state

SecureBoot enabled

  注意：在禁用了安全引导的系统上，将 mokutil 命令与任何变量一起使用将显示以下输出：  

＃mokutil -l

EFI 变量在这个系统上不被支持

问：在安装了更新的软件包后，是否需要重新引导或重新启动系统？

答：是的，需要重新启动以确保正在使用更新的组件。

问：容器会受到什么影响？

答：虽然基于 Red Hat Enterprise Linux 的容器不会直接受到这个问题的影响，但它们的安全性取决于主机内核环境的安全性。红帽建议更新到最新的镜像，并把运行容器的主机更新到最新版本。为了保护使用容器的隐私，用户需要对容器主机（如 Red Hat Enterprise Linux 或 Atomic Host）应用并部署更新。 

问：我正在运行 Red Hat Enterprise Linux 7，无法更新内核版本。我是否应该将内核版本中的哈希值注册到受信任的数据库中？

答：不需要。用于 Red Hat Enterprise Linux 7 的较早内核版本将自动添加到 shim 的允许列表中。

问：我正在运行 Red Hat Enterprise Linux 8，是否应该将内核版本中的哈希值注册到受信任的数据库中？

答：是的，默认情况下旧的 Red Hat Enterprise Linux 8内核版本不被信任。为了引导到以前的内核版本，您可以以 root 用户身份执行以下命令：

# pesign -P -h -i /boot/vmlinuz-<version>

# mokutil --import-hash <hash value returned from pesign command>

# reboot

问：如果没有使用安全引导机制，在将此更新应用到 GRUB 之后，是否可以在不做任何改变的情况下，继续启动到 RHEL 7 和 8 内核的早期版本中？ 

答：是的，如果禁用了“安全引导”选项，则不会执行签名验证，因此以前的内核版本仍然可以启动，而无需采取任何其他措施。

问：新的 DBX 更新将在何时应用到 UEFI 固件？

答：由于 GRUB 的安全漏洞，以前的红帽安全引导签名将被吊销并放入Disallow DB（DBX）数据库中，当客户应用 dbxtool 更新时将使用新的签名。更新中包含了一个新的 DBX 文件，同时还包含了对旧红帽密钥的吊销。但是，在默认情况下不会执行 dbxupdate，dbxupdate 适用于希望排除旧密钥的 IT 专业人员。未来几个月内将发布一个新的、强制性的、自动的 dbxtool 更新，以为所有红帽客户无限期撤消相关的红帽密钥。  

问：该漏洞会影响独立于安全引导机制运行的程序代码。那么，启用安全引导的系统与其他系统之间，漏洞的影响有何不同？

答：安全引导机制旨在限制计算机固件和后续加载程序组件仅加载未经修改的、受信任并被签名的代码。这意味着，安全引导机制提供了一个额外的安全边界，可防止在启动阶段（引导加载程序、内核和内核模块）尝试加载不受信任的软件的情况。由于 GRUB 2 漏洞允许执行任意代码，因此攻击者可以利用此漏洞绕过任何签名检查，或跨越安全引导机制所建立的安全边界运行不受信任的代码，从而破坏了加载内核的安全性。 

如果禁用了安全引导机制，则不执行签名验证。因此，没有建立额外的安全边界。鉴于此缺陷允许加载任何代码，对于未启用安全引导机制的 GRUB，此缺陷可以与允许任意代码执行的任何其他缺陷一样处理。

问：在应用了 RHSA-2020:3216 或 RHSA-2020:3217后，出现了在 POST 后系统挂起且 grub 菜单不会被加载的问题。我应该怎么办？

答：请参阅 https://access.redhat.com/solutions/5272311。2020 年 8 月 1 日星期六，红帽发布了一个更新的 shim 软件包，这个更新版本解决了此问题。我们强烈建议红帽的客户不要使用 RHSA-2020:3216 或 RHSA-2020:3217 所提供的较旧版本的 shim 软件包，而应使用 RHBA-2020:3262 和 RHBA- 2020:3265 附带的（或更新的） shim 软件包。  

致谢

红帽感谢 Eclypsium 的Jesse Michael 和 Mickey Shkatov 发现并报告了此漏洞。红帽还感谢行业合作伙伴和 GNU GRUB 社区在此问题上的合作。 

参考信息

• Eclypsium - There's a Hole in the Boot 
• 如何在 dbxtool 更新中应用更新的 DBX 文件
• 使用 GRUB 2
• 现代计算机安全解决方案中的 UEFI 安全引导
• 如何使用 GPG 来验证产品安全中的签名内容