Pi-hole FTL v5.7 and Web v5.4 released

Today, we release Pi-hole FTL v5.7 and Web v5.4. This release improves the security and reliability of your Pi-hole. The most important enhancements are summarized below:

Fix security flaws on the web interface

Thanks to Veno Eivazian who pointed us to three security flaws in the web interface. They could have been used to run JavaScript code in the user browser and to “steal” the login session. The latter shouldn’t cause any headaches for you as one should never run a Pi-hole open to the web. However, a possible malicious client inside your home network could have exploited them.

We have mitigated the three raised security issues by regenerating session ID on successful login (to prevent session fixation), by restricting PHP sessions to be cookie-only, by restricting the session cookie to be kept secret from possible malicious JavaScript code, and by encoding a message after failed cross-origin resource sharing (CORS) checking.

Inbuilt enhanced Denial-of-Service (DoS) protection

A DoS attack is a type of cyber attack in which a malicious actor attempts to make a service inaccessible to its intended users by disrupting the normal function of the device. DoS attacks typically work by overwhelming (flooding) a target with requests until normal traffic can no longer be processed. For other users, it then results in a denial of service. When facing the Internet, services have to be hardened against malicious attacks such as Denial-of-Service (DoS) attacks. Defensive responses to denial-of-service attacks typically involve special DoS protection systems but can also involve routers (Access control list (ACL) capabilities) and firewall rules (rate-limiting).
However, inside your local home network, you typically don’t set up proper countermeasures. This is perfectly fine as they are typically not needed. Nevertheless, we see quite often that “the Internet was taken down” (DNS resolution went unavailable) when a rogue client starting to hammer a blocked domain thousands of time every second, or, when an (accidentally) created DNS loop exists, e.g., between the router and your Pi-hole.

It is an interesting question how this should be solved and the simplest approach seems to be firewalling them away. However, we thought that this is not the best way to handle this because

1. Users may already have configured a firewall and checking which firewall was used together with foreseeing any possible conflicts with existing rules is next to impossible.
2. Simply blocking them seems counter-intuitive as the clients requesting clients never see that something is wrong.

Hence, we decided to implement a customizable rate-limiting into FTL itself. It defaults to the rather conservative limit of allowing no more than 1000 queries in a 60 seconds window for each client. Afterwards, any further queries are replied to with empty replies with the status set to REFUSED. Both the number of queries within the window as well as the window size can be configured by the user. It is important to note that rate-limiting is happening on a per-client basis. Other clients can continue to use FTL while rate-limited clients are short-circuited at the same time.

Rate-limiting can easily be disabled by setting RATE_LIMIT=0/0 in /etc/pihole/pihole-FTL.conf. If I want, say, to set a rate limit of 1 query per hour, the option should look like RATE_LIMIT=1/3600.

1000 queries in 60 seconds still permits more than one million queries per device in 24 hours. Hence, we believe this is not really a breaking change but should still prevent your Pi-hole from being DoSed away.

Improve interoperability with systemd-resolved

We implemented a mitigation for a long-standing bug in systemd-resolved that can lead to up to 5 seconds of artificial DNS resolution delay on respective clients. With the new version of FTL, systemd-resolved accepts blocked queries without any artificial delay.

Improve shared memory robustness

Our FTL engine is a heavily multi-threaded application using both threads and forks to give you the best and fastest DNS service. To communicate between individual forks, it uses shared memory. If multiple independent processes work on the same shared memory at the same time this can easily lead to issues with memory being written to / resized in an undefined manner. This new version of FTL detects if already existing shared memory blocks are in use by other processes and refuses to start in this case. This ensures that inconsistent shared memory cannot occur.

Other fixes, tweaks, and improvements

Furthermore, we address a few minor glitches, e.g., with percentages not exactly adding up to 100% or incorrect warnings in Pi-hole’s log files.