An heap-based buffer overflow was discovered in dnsmasq in the way it sorts RRSets before validating them with DNSSEC data. An attacker, who can forge DNS replies such as that they are accepted as valid, could use this flaw to cause an overflow with arbitrary data in a heap-allocated memory, possibly executing code on the machine.
To trigger the flaw, dnsmasq has to be compiled with HAVE_DNSSEC flag and DNSSEC has to be enabled (e.g. with --dnssec option). Moreover, the attacker shall either control a DNS server used in the domain name resolution process or be able to inject packets on the network in such a way to trick dnsmasq into accepting them (e.g. guessing the ID, random port used, etc.). To be involved in the domain name resolution process, an attacker could trick a victim which uses dnsmasq into accessing some resources on a controlled domain, e.g. trick the user to visit a website or open an email.
The flaw lies in dnssec.c:sort_rrset() and it can be triggered in two ways though the issue is the same. Function sort_rrset() works indeed on two buffers, buff1 and buff2, and it does almost the same operation on both, thus it is possible to trigger the flaw on one or the other buffer. When get_rdata() returns 0, a `memcpy (buffX + leftX, pX, lenX)` is performed, where X could be 1 or 2, based on the buffer it is working on. However `lenX` is computed based on `endX`, which is directly under the attacker control as it comes from RDLENGTH field of the DNS reply. By providing specially crafted DNS replies, an attacker can overflow buff1 or buff2 with arbitrary data.
According to OSD 3 architecture dnsmasq is automatically configured on all masters and nodes. The pods use the nodes as their DNS, and the nodes forward the requests. And not seems to be a part of RHEL 7. Seems that all OSD 3 services may be affected by this dnsmasq.
OSDv4 uses the dns operator (which uses CoreDNS) instead of dnsmasq, so its not affected
Statement: This issue does not affect the versions of dnsmasq as shipped with Red Hat Enterprise Linux 5, 6, and 7 as they are not compiled with DNSSEC support.
Mitigation: The only known way to mitigate this flaw is to disable DNSSEC altogether, by removing the `--dnssec` command line option or the `dnssec` option from dnsmasq configuration file.
Acknowledgments: Name: Moshe Kol (JSOF), Shlomi Oberman (JSOF)
External References: https://www.jsof-tech.com/disclosures/dnspooq/
Created dnsmasq tracking bugs for this issue: Affects: fedora-all [bug 1917781]
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.1 Extended Update Support Via RHSA-2021:0152 https://access.redhat.com/errata/RHSA-2021:0152
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:0150 https://access.redhat.com/errata/RHSA-2021:0150
Upstream patch: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=4e96a4be685c9e4445f6ee79ad0b36b9119b502a
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.2 Extended Update Support Via RHSA-2021:0151 https://access.redhat.com/errata/RHSA-2021:0151
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-2020-25681