DNSpooq - dnsmasq 中的多个安全漏洞（CVE-2020-25681、CVE-2020-25682、CVE-2020-25683、CVE-2020-25684、CVE-2020-25685、CVE-2020-25686、CVE-2020-25687)

摘要

红帽已获知在 dnsmasq（通常被称为 DNSpooq） 中存在多个安全漏洞。dnsmasq 是一个轻量级的工具程序，用来为私有网络和虚拟化环境提供包括 DNS 和 DHCP 在内的网络服务。这些问题包括在 dnsmasq 所提供的 DNS 服务中，可能会被远程攻击者利用来一定程度上控制 dnsmasq 客户端系统，将用户重定向到错误的站点，或在运行 dnsmasq 的机器上执行代码。

其中的两个安全漏洞（CVE-2020-25681 和 CVE-2020-25682），由于能够在 dnsmasq 机器上远程执行代码，这两个安全漏洞的严重性等级被定为 Important（重要）。CVE-2020-25683、CVE-2020-25684、CVE-2020-25685、CVE-2020-25686 和 CVE-2020-25687 的严重性等级被定为 Moderate（中度）。

CVE-2020-25681、CVE-2020-25682、CVE-2020-25683 和 CVE-2020-25687 都需要 DNSSEC 被编译并在 dnsmasq 配置中启用。因此，以下红帽产品在使用非默认配置时会受到影响：

• Red Hat Enterprise Linux 8

CVE-2020-25684、CVE-2020-25685 和 CVE-2020-25686 可能允许攻击者破坏 DNS 的缓存数据，并将用户重定向到错误的站点。以下红帽产品版本会受到影响：

• Red Hat Enterprise Linux 6

• Red Hat Enterprise Linux 7

• Red Hat Enterprise Linux 8

以下红帽产品也有可能会受到影响，因为它们会从 Red Hat Enterprise Linux 频道中抓取 dnsmasq。请确保底层的 Red Hat Enterprise Linux 中的 dnsmasq 软件包是最新的，并参考 libvirt 用例以获取更多信息。

• Red Hat OpenStack Platform 10

• Red Hat OpenStack Platform 13

• Red Hat Virtualization 4.3

• Red Hat Virtualization 4.4

请参照下面的诊断部分的内容，检查您的系统当前是否存在这些安全漏洞。

技术概述

dnsmasq 中的这七个问题被分为两组：

• dnsmasq 将传入的 DNS 回复与以前转发的查询进行匹配的方式中的漏洞（CVE-2020-25684、CVE-2020-25685 和 CVE-2020-25686）。

• 在为验证准备 DNSSEC 数据的代码中存在缓冲区溢出的问题造成的漏洞（CVE-2020-25681、CVE-2020-25682、CVE-2020-25683 和 CVE-2020-25687）。

要利用第二类漏洞，攻击者需要 dnsmasq 客户端的协作，或使用某种方式使客户端启动一系列对 dnsmasq 的与攻击者控制的域相关的 DNS 查询。

第一组漏洞可以被用来破坏 DNS 缓存中的数据，这将影响所有使用 dnsmasq 作为DNS 服务器的客户端，为其提供错误的名称解析。当将这些漏洞组合在一起时，可以在几分钟内对系统执行安全攻击。

第二类漏洞需要在 dnsmasq 中启用 DNSSEC，并可以通过对开放转发查询发送一组经过特殊设计的响应，在 DNSSEC 数据被验证前触发这些漏洞。

根据具体情况，利用这些漏洞进行安全攻击所造成的结果会有所不同。对于 CVE-2020-25681 和 CVE-2020-25682，在主机上可能会出现远程执行恶意代码的情况，因此它们的严重性被定为 Important（重要）。CVE-2020-25683 和 CVE-2020-25687 仅会导致 dnsmasq 服务崩溃，它们的严重性等级为 Moderate（中度）。

请注意，即使 dnsmasq 没有被用户启动，它也可以由 libvirt 自动运行以向客户虚拟机提供 DNS 服务。此外，NetworkManager 也可能会被配置为使用 dnsmasq 向系统提供 DNS。

请参考背景信息部分的内容，以获取有关安全漏洞的更多信息。

缓解措施

禁用 dnsmasq 缓存可以减少 CVE-2020-25684、CVE-2020-25685 和 CVE-2020-25686 的影响。方法是在调用 dnsmasq 时使用 `--cache-size=0`，或在 dnsmasq 配置文件中（默认是 /etc/dnsmasq.conf）添加一个带有 `cache-size=0` 的行。

当使用带有 libvirt 的 Red Hat Enterprise Linux 8.3（通过一个 virt:rhel 模块）时，使用 `virsh net-edit <network-name>` 并参照 https://libvirt.org/formatnetwork.html#elementsNamespaces 添加推荐的选项 `cache-size=0`。

当使用 8.3 之前的 Red Hat Enterprise Linux 版本时，无法自定义由 libvirt 生成的 dnsmasq 配置。如果 dnsmasq 正在通过 NetworkManager 运行，在 /etc/NetworkManager/dnsmasq.d/ 中创建一个新文件，并向其中添加`cache-size = 0'。

在所有情况中，在禁用缓存时，由于所有 DNS 查询都需要转发到上游服务器，您环境的性能会有一定损失。在应用缓解措施之前，请评估缓解措施是否适合于您的系统环境。

缓解 CVE-2020-25681，CVE-2020-25682，CVE-2020-25683 和 CVE-2020-25687 的一个唯一的已知方法是，通过删除 `--dnssec` 命令行选项，或从 dnsmasq 配置文件中删除 dnssec` 选项来完全禁用 DNSSEC。

我们建议在 dnsmasq 更新可用时尽早应用 dnsmasq 更新。

技术细节

CVE-2020-25681

在使用 DNSSEC 数据进行验证之前，在 RRSets 进行排序的过程中发现了一个基于堆的缓冲区溢出。一个网络中的攻击者可以利用这个漏洞，伪造 DNS 回复（例如被接受为有效的回复），导致堆内存段中任意数据的缓冲区溢出，从而可能在系统中执行代码。

CVE-2020-25682

在使用 DNSSEC 数据验证 DNS 数据包之前，dnsmasq从 DNS 数据包中提取名称的方式中发现了一个缓冲区溢出漏洞。网络中的一个可以创建有效 DNS 回复的攻击者，可以利用这个漏洞，导致堆内存段中任意数据的缓冲区溢出，从而可能在系统中执行代码。这个漏洞存在于 rfc1035.c:extract_name() 函数中，可将数据写入由名称指向的内存中，该函数会假定缓冲区中有 MAXDNAME * 2 字节的空间。但是，在某些代码执行路径中，有可能会为extract_name() 提供一个针对基本缓冲区的偏移量，从而在实际上减少了可写入缓冲区的可用字节数。

CVE-2020-25683

在启用 DNSSEC 且在验证接收到的 DNS 条目之前，在dnsmasq 中发现了一个基于堆的缓冲区溢出。一个可以创建有效 DNS 回复的远程攻击者，可以利用此漏洞在堆分配的内存中引发一个溢出行为。此漏洞是由于 rfc1035.c:extract_name() 缺少长度检查造成的，这有可能会导致代码在 get_rdata() 中执行一个带有一个大小为负值的 memcpy()，从而导致 dnsmasq 崩溃，并最终导致拒绝服务问题。

CVE-2020-25684

从转发的查询中获取答复时，dnsmasq 会在 forward.c:reply_query() 中检查是否有待处理的转发查询使用了答复目标的地址/端口。但是，它并不会使用地址/端口来检索确切的转发查询，从而大大减少了网络中的攻击者伪造答复并使 dnsmasq 接受答复的尝试次数。此问题与 RFC5452 不符，RFC5452 会指定一个查询属性，所有查询都必须使用它来匹配答复。通过这个漏洞，攻击者可以对系统执行 DNS 缓存中毒攻击。在与 CVE-2020-25685 或 CVE-2020-25686 组合在一起，使安全攻击可以成功的复杂性会减小。

CVE-2020-25685

在从转发的查询中获取答复时，dnsmasq 会检查 forward.c:reply_query()。forward.c:reply_query() 是与回复相匹配的转发查询，当它仅使用了查询名称的弱哈希值。由于较弱的哈希值（当在没有 DNSSEC 的情况下编译 dnsmasq 时为 CRC32，在有的情况下是 SHA-1），一个没有处于相关路线中的攻击者，可以找到具有相同哈希值的多个不同域，从而大大减少了为了达到伪造一个答复并使它被 dnsmasq 接受的目的，攻击者需要进行尝试的次数。。这与 RFC5452 不同，RFC5452 会指定，查询名称是必须用于匹配答复的查询的属性之一。通过这个漏洞，攻击者可以对系统执行 DNS 缓存中毒攻击。在与 CVE-2020-25684 组合在一起，使安全攻击可以成功的复杂性会减小。

CVE-2020-25686

当收到一个查询时，dnsmasq 不会检查是否存在相同名称的待处理请求，而是转发新请求。默认情况下，最多可以将 150 个待处理查询发送到上游服务器，因此最多就有可能有 150 个具有相同名称的查询。对于一个没有处于相关路线中的攻击者，为了达到伪造一个答复并使它被 dnsmasq 接受的目的，需要进行尝试的次数会大幅减少。在 RFC5452 中的“Birthday Attacks（生日攻击）”部分中提到了此问题。如果与 CVE-2020-25684 组合在一起，则会降低成功攻击的复杂性。

CVE-2020-25687

在启用 DNSSEC 且在验证接收到的 DNS 条目之前，在dnsmasq 中发现了一个基于堆的缓冲区溢出。一个可以创建有效 DNS 回复的远程攻击者，可以利用此漏洞在堆分配的内存中引发一个溢出行为。此漏洞是由于 rfc1035.c:extract_name() 缺少长度检查造成的，这有可能会导致代码在 sort_rrset() 中执行一个带有一个大小为负值的 memcpy()，从而导致 dnsmasq 崩溃，并最终导致拒绝服务问题。

背景信息

DNS（Domain Name System ）主要被用于将域名（如 www.example.com）转换为 IP 地址（例如 127.0.0.1 和 2001:DB8::/32）。它以一个分布式系统的形式进行组织，没有一个单一的节点知道所有的域和转换信息。解析一个名称可能需要来自多个服务器的多个查询和响应，直到达到知道所请求名称的名称服务器为止。这整个过程被称为 DNS 解析过程。

DNS 有几个安全限制，特别是，它不能保证任何涉及的服务器或其他外部攻击者都不会提供伪造的信息。DNS 主要通过在 DNS 回复/查询中使用一个随机的 16 位标识符，以及随机的 UDP 源端口，以防止外部攻击者劫持 DNS 的通信。DNSSEC 的开发旨在在 DNS 之上添加一层，以提供 DNS数据的原始身份验证和完整性保证。在使用时，它将签名与可以由其他系统验证的实际 DNS 数据相关联，以确保所提供的答案实际上来自该域的权威服务器，并且没有被其他人伪造。如果被应用，DNSSEC 验证可以防止 DNS 缓存中毒攻击。但是，目前它还未被广泛采用。

dnsmasq 是一个轻量级的工具程序，用来为小型私有网络和虚拟化环境提供包括 DNS 和 DHCP 在内的网络服务。它的 DNS 服务主要作为一个转发器，该转发器从客户端获取 DNS 查询，将其转发到一组预先配置的上游 DNS 服务器，然后缓存答复，以便下一次由同一或另一个客户端进行相同的查询时，可以立即返回答复，而无需再次询问上游服务器。它也可以将其配置为执行 DNSSEC 验证。

对 dnsmasq 客户端具有一定控制权限的攻击者，可以利用 CVE-2020-25684、CVE-2020-25685 和 CVE-2020-25686，精心设计一组 DNS 回复，并诱使 dnsmasq 向处理来自预先配置的上游 DNS 服务器的查询一样接受它们。如果启用了缓存（默认行为），这些错误的答复也会被缓存并提供给其他客户端，从而将它们重定向到潜在的恶意站点。此问题被称为 DNS 缓存中毒（DNS Cache Poisoning）攻击。这些缺陷极大地减少了攻击者猜测 16 位标识符和用于特定 DNS 查询的特定 UDP 端口的尝试次数。因为考虑到攻击不具有确定性，且需要花费一些时间来猜测值的正确组合，所以攻击者需要一个 dnsmasq 客户端才能开始对攻击者选择的域执行多个 DNS 查询（例如，用户在访问恶意网站时，网络浏览器就有可能触发 DNS 解析过程，从而使攻击者可以控制一个客户端系统，或者对客户端系统造成破坏）。

当 dnsmasq 被配置为使用 DNSSEC 时，它容易受到利用 CVE-2020-25681、CVE-2020-25682、CVE-2020-25683 和 CVE-2020-25687 的攻击。这些漏洞可以被对dnsmasq 客户端具有某种控制权的远程攻击者利用，在运行 dnsmasq 的系统上远程执行代码或导致其崩溃，从而导致 dnsmasq 客户端出现拒绝服务的问题，并无法提供解析域名的服务。

产品影响

Red Hat Enterprise Linux 8

默认情况下，dnsmasq systemd 服务被禁用，NetworkManager 未配置来使用它。

Red Hat Enterprise Linux 8 所提供的 dnsmasq 版本会受到本文档中提到的所有 CVE 的影响。但是，在其默认配置中，Red Hat Enterprise Linux 8 不会启用 DNSSEC，因此不受 CVE-2020-25681、CVE-2020-25682、CVE-2020-25683 和 CVE-2020-25687 的影响。

Red Hat Enterprise Linux 7 / Red Hat Enterprise Linux 6

默认情况下，dnsmasq systemd 服务被禁用，NetworkManager 未配置来使用它。

Red Hat Enterprise Linux 6 和 7 所提供的 dnsmasq 版本只会受到 CVE-2020-25684、CVE-2020-25685 和 CVE-2020-25686 的影响。

由于 DNSSEC 未在 dnsmasq 软件包中进行编译，因此Red Hat Enterprise Linux 6 和 7 不会受到其他安全漏洞的影响。

Libvirt 用例

除非被明确禁用，否则 dnsmasq 将使用系统的解析器作为上游 DNS 服务器来为 libvirt 客户机提供 DNS 服务。具有对客户机系统的控制权或能够欺骗客户机系统对攻击者控制的域执行多个 DNS 查询的攻击者，可以利用 CVE-2020-25684、CVE-2020-25685 和 CVE-2020 -25686 毒化 dnsmasq 缓存，并影响连接到同一虚拟网络的所有客户机。除非 DNSSEC 被手工配置，libvirt 中使用的 dnsmasq 不会受 CVE-2020-25681、CVE-2020-25682、CVE-2020-25683 和 CVE-2020-25687 的影响。

服务影响

对于所有 OpenShift v3 集群，包括：Red Hat OpenShift Online、OpenShift Dedicated、Microsoft Azure Red Hat OpenShift：

dnsmasq 在 OpenShift Dedicated v3 中使用。 OpenShift v3集群中使用的 dnsmasq 是通过 Red Hat Enterprise Linux 7 软件包提供的，v3 集群不受 DNSSEC 漏洞的影响。

对于非 DNSSEC 漏洞，OpenShift Dedicated 3 服务会受到影响，因为它们使用的是由 Red Hat Enterprise Linux 7 提供的软件包。每个节点都使用 dnsmasq，并且没有任何保护措施可以防止攻击者对 DNS 进行缓存中毒攻击。

对于所有 OpenShift v4 集群，包括：OpenShift Dedicated 集群：

OpenShift Dedicated v4 使用 DNS operator（使用CoreDNS）而不是 dnsmasq。OpenShift v4 集群不受 dnsmasq 漏洞的影响。我们已验证，v4 中没有使用 dnsmasq 的集群。

受 CVE 影响的红帽产品

受影响产品的更新

我们强烈建议，所有运行受影响版本的红帽产品的用户，在相关勘误可用后尽快进行更新。用户应立即应用可用的更新并根据需要启用缓解措施。

[1] 公告/更新链接将在更新发布后添加。

[2]什么是 Red Hat Enterprise Linux Extended Update Support (EUS) 订阅?

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

[4]什么是 Red Hat Enterprise Linux SAP Solutions 订阅?

诊断

一个安全漏洞检测脚本已被开发，用来检查您的系统当前是否存在相关的安全漏洞。您可以下载 GPG 签名来验证脚本的真实性。红帽客户门户网站上提供了有关如何使用GPG签名进行验证说明。

常问问题解答

问：如果在我们私有的网络中使用 dnsmasq 提供 DNS，我们的系统是否容易受到这些漏洞的影响？

答：攻击者需要从私有网络中向存在漏洞的 dnsmasq 实例提交多个 DNS 查询，因为攻击需要一些猜测才能绕过基本的 DNS 保护。DNS 查询可能以多种方式触发，从完全控制网络上的系统，到欺骗网络上连接的受害用户打开电子邮件或网站。有了足够数量的 DNS 查询，即使在私有网络上，也可以利用这些缺陷。

问：如果我的系统使用 libvirt，通过这些漏洞是否会出现从客户机到主机的逃逸问题？

答：攻击者需要一个客户机的某种形式的协作才能发起使用利用这些漏洞的攻击。如果攻击者可以从一个客户机系统对 dnsmasq 发动多个 DNS 查询，则有可能会滥用本文中所提到的缺陷使它的缓存出现“中毒”问题。如果在 libvirt 中使用的 dnsmasq 中手动配置了DNSSEC（非默认配置），则也有可能在主机中执行代码或使 dnsmasq 服务器崩溃。

问：在升级了 dnsmasq 软件包后需要采取哪些步骤来确保系统不再有相关的安全漏洞？

答：所有运行了 dnsmasq 的实例都需要被重启。最直接的方法是，重新启动所有使用 dnsmasq 的系统，包括虚拟化主机和客户机。由于 dnsmasq 实例可能会被 libvirt 和其他系统组件运行，因此必须重新启动这些组件。在不重新启动的情况下重新运行这些实例的过程会针对不同组件而有所不同。例如，所有使用 dnsmasq 的 libvirt 网络，都需要重新运行并重新附加到相应的虚拟机。这会对环境产生影响，因此必须针对每种环境分别进行定制并进行测试。

致谢

红帽感谢 Moshe Kol 和 Shlomi Oberman（JSOF）报告此漏洞。

参考信息

JSOF 关于 DNSpooq 的研究文章

如何使用 GPG 来验证产品安全中的签名内容