Bug 1939368 (CVE-2021-3448)
|Summary:||CVE-2021-3448 dnsmasq: fixed outgoing port used when --server is used with an interface name|
|Product:||[Other] Security Response||Reporter:||Riccardo Schirone <rschiron>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||aegorenk, code, dns-sig, dougsland, jima, jjoyce, jschluet, laine, lhh, lpeer, mburns, pemensik, sclewis, security-response-team, slinaber, veillard|
|Fixed In Version:||dnsmasq 2.85||Doc Type:||If docs needed, set a value|
A flaw was found in dnsmasq. When configured to use a specific server for a given network interface, dnsmasq uses a fixed port while forwarding queries. An attacker on the network, able to find the outgoing port used by dnsmasq, only needs to guess the random transmission ID to forge a reply and get it accepted by dnsmasq. This flaw makes a DNS Cache Poisoning attack much easier. The highest threat from this vulnerability is to data integrity.
|Last Closed:||2021-11-09 18:23:40 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1939965, 1939966, 1939967|
|Bug Blocks:||1937373, 1939697|
Description Riccardo Schirone 2021-03-16 08:56:08 UTC
When configured with --server=<address>@<interface> or similar (e.g. through dbus), dnsmasq configures a fixed UDP port for all outgoing queries to the specified upstream DNS server. If an attacker is able to discover the opened port through other means (e.g. port scanning, guessing or sniffing), he would just have to guess the random transmission ID to forge a reply and get it accepted by dnsmasq. This flaw could be abused to perform a DNS Cache Poisoning attack.
Comment 1 Riccardo Schirone 2021-03-16 08:57:46 UTC
Acknowledgments: Name: Petr Mensik (Red Hat)
Comment 3 Riccardo Schirone 2021-03-16 09:30:03 UTC
When dns=dnsmasq is set in NetworkManager.conf, NetworkManager configures dnsmasq with the equivalent of --server=<address>@<interface>, enabling the preconditions to trigger this issue.
Comment 4 Riccardo Schirone 2021-03-16 09:51:16 UTC
To exploit this flaw, an attacker has to be able to: 1) initiate a DNS query to the dnsmasq server 2) forge a reply with the upstream DNS server as source IP 3) make the forged reply arrive before the real one 4) know, through other means, the fixed outgoing port used by dnsmasq 5) guess the transmission ID, composed of 16bits In a not-vulnerable configuration, an attacker would have to guess the right combination of (outgoing-port;transmission ID). Due to this flaw however, he just needs to find out the outgoing port through other means, like sniffing, scanning, etc. Once the outgoing port is discovered, it can be used to guess the transmission ID in a quicker way, due to the port being reused for all queries going through the same interface.
Comment 9 Riccardo Schirone 2021-03-17 10:51:22 UTC
Mitigation: The flaw can be prevented by removing `--server=<address>@<interface>` option or by removing the directive `server=<address>@<interface>`. If dnsmasq is being run through NetworkManager, please be aware that NetworkManager automatically configures dnsmasq to use the `server=<address>@<interface>` directive, thus in this case the only way to prevent the flaw is to remove `dns=dnsmasq` from /etc/NetworkManager/NetworkManager.conf file. If the `server=<address>@<interface>` must be kept active, the impact of this flaw can be reduced by disabling the dnsmasq cache by adding `--cache-size=0` when calling dnsmasq or by adding a line with `cache-size=0` to the dnsmasq configuration file (/etc/dnsmasq.conf by default). If dnsmasq is being run through NetworkManager, create a new file in /etc/NetworkManager/dnsmasq.d/ and add `cache-size=0` to it. By disabling the cache, you may experience a performance loss in your environment due to all DNS queries being forwarded to the upstream servers. Please evaluate if the mitigation is appropriate for the system’s environment before applying.
Comment 10 Riccardo Schirone 2021-03-17 11:08:37 UTC
Created dnsmasq tracking bugs for this issue: Affects: fedora-all [bug 1939965]
Comment 13 Riccardo Schirone 2021-04-08 07:51:52 UTC
Comment 14 Riccardo Schirone 2021-04-08 07:52:32 UTC
dnsmasq 2.85, which fixes this issue, announced: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q2/014962.html
Comment 17 errata-xmlrpc 2021-11-09 17:25:22 UTC
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:4153 https://access.redhat.com/errata/RHSA-2021:4153
Comment 18 Product Security DevOps Team 2021-11-09 18:23:38 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2021-3448