Pi-hole FTL v5.5 released – UPDATE TODAY

Pi-hole FTL v5.5 released – UPDATE TODAY

2021-01-19 Updates 10

In September 2020, the JSOF Research Lab discovered seven security vulnerabilities in dnsmasq. They named the set of vulnerabilities dnspooq. We’ve been in contact with them and, over the last couple of weeks, we’ve partnered and worked closely with Cisco, Red Hat and, Simon Kelley (the maintainer of dnsmasq) [the order of mentioning does not imply anything] to fix the discovered vulnerabilities. It was agreed upon to keep the discovered vulnerabilities private until fixes are published to allow our users adequate time to test and install updates before exploits are easily available.

Today we release an important security update for the DNS and DHCP server dnsmasq working at the very heart of pihole-FTL. As usual, we want to ship security fixes as soon as possible. It is not yet clear when the major distributions will receive the new version and if the fixes will at all be backported into older OS releases.

In this blog post, we provide a small write-up of the technical details for those that are interested. If not, you can simply update your Pi-hole using pihole -up to immediately receive and automatically apply the new security fixes without having to read anything here.

The JSON research lab found that dnsmasq is vulnerable to a DNS cache poisoning attack by an off-path attacker (i.e., an attacker that does not observe the communication between the DNS forwarder and the DNS server). Their attack allowed for the poisoning of multiple domain names at once and is a result of several vulnerabilities found. The importance of this vulnerability is underlined by their demonstration of being able to complete such an attack successfully within only seconds (up to only a few minutes) without any special requirements on the configuration of the server. The attack is possible directly from the Internet and affects about 1 million (!) open dnsmasq instances. This is also again the point where we should point out that running an open resolver is a really bad idea and that accessing your Pi-hole over an encrypted channel (such as a Wireguard VPN) is fairly easy to set up and gives you a lot of extra benefits.

In addition to the cache poisoning attack, JSOF research lab found a critical heap-buffer overflow vulnerability that could potentially lead to remote code execution. As the vulnerability resides in the early stages of DNSSEC validation, DNSSEC’s defense against DNS attacks is rendered ineffective. As Pi-hole always takes security very important, we have a few countermeasures always in place to mitigate such vulnerabilities. This ensures that – even if your Pi-hole would be taken over in such an attack – common attack like those from cryptovirology that threatens to publish the victim’s data or perpetually block access to it unless a ransom is paid, cannot happen as our daemon can neither read nor change data from other users on the system.

Further buffer-overflow vulnerabilities they found can “only” lead to DoS (denial of service) attacks taking your DNS resolution down.

You can find the full technical report on the website of JSOF Research Lab here: JSOF Research Lab – DNSpooq – Kaminsky attack is back!

Red Hat describes the issues here: Red Hat – DNSpooq – Multiple vulnerabilities within dnsmasq

The relevant changes to fix the vulnerabilities described above are nicely summarized in dnsmasq‘s CHANGELOG for version 2.83:

  • Use the values of min-port and max-port in outgoing TCP connections to upstream DNS servers.
  • Fix a remote buffer overflow problem in the DNSSEC code. Any dnsmasq with DNSSEC compiled in and enabled is vulnerable to this, referenced by CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, CVE-2020-25687.
  • Be sure to only accept UDP DNS query replies at the address from which the query was originated. This keeps as much entropy in the {query-ID, random-port} tuple as possible, to help defeat cache poisoning attacks. Refer: CVE-2020-25684.
  • Use the SHA-256 hash function to verify that DNS answers received are for the questions originally asked. This replaces the slightly insecure SHA-1 (when compiled with DNSSEC) or the very insecure CRC32 (otherwise). Refer: CVE-2020-25685.
  • Handle multiple identical near-simultaneous DNS queries better. Previously, such queries would all be forwarded of the query. The new behavior detects repeated queries and merely stores the clients sending repeats so that when the first query completes, the answer can be sent to all the clients who asked. Refer: CVE-2020-25686.

Next to the update of the embedded dnsmasq, this release also contains a few other bug fixes plus some memory usage improvements. In addition, we also released two small bug fixes for Pi-hole Core and Web so all components can be updated.

Notable Replies

  1. It doesn't always reflect immediately, but it's in the footer of the page where the versions are shown:

    It will say "update available" here. Though I can't remember off the top of my head how often that check is done. @DL6ER might remember....

  2. is every dns provider (google, cloudflare) vulnerable to these vulnerabilities and has to fix them himself? Does that mean pihole is safer?

  3. Github is reporting issues. This is probably why your download failed and outside of where we can so something to fix it.

  4. Once a day

  5. Oh, nearly forgot...

    @anon55913113 FYI - new update. It's an important one.

Continue the discussion discourse.pi-hole.net

5 more replies

Participants