Pi-hole FTL v6.7.1 ships fixes for four security flaws

Pi-hole has released FTL 6.7.1, a security update that fixes four flaws in the DNS engine behind the network-wide ad blocker, three of them rated High. The release also takes two of the tool's riskiest settings out of the web interface and the API.

Two routes to running code

Both of the High-severity code-execution bugs turn configuration options into a way in. The first, GHSA-2794-hrj8-5jg9, sits under webserver.advancedOpts, where the validation that blocks entries such as lua_* leaves other options free to cause trouble; the reporter showed an arbitrary file read as the pihole user and a route to root. It affects FTL from version 6.3 onwards.

The second, GHSA-ww5x-xx4x-qvjr, is the more direct of the pair. The misc.dnsmasq_lines option exists to append lines to dnsmasq's configuration, and each entry is written in verbatim after a check for newlines and nothing else. That means exec-capable dnsmasq directives such as dhcp-script= and dhcp-luascript= are accepted and honoured, giving code execution as the pihole-FTL service user. It is reachable through the web interface and the configuration API, and affects every release from 6.0 onwards.

Both need an authenticated web or API session, or an instance running in no-password mode. That precondition is worth repeating, because it is the difference between a flaw that matters on a router in a shared house and one that matters on a locked-down network.

The review that found three more

The third advisory, GHSA-gx63-h4w6-f46g, is a product of fixing the first. Working through the surrounding code, Pi-hole's maintainer found that its configuration validators could be walked around in four independent ways - through Teleporter imports, through combined changes and through document-root relocation. Each let an administrator put a value into the running configuration that every other configuration path refuses. The project's own assessment is that the most serious of the four defeats fixes shipped for a series of earlier advisories.

The fourth flaw is a memory-safety bug rather than a permissions one. GHSA-7997-2868-rjfg describes a stack buffer overflow in the function that builds blocked answers: a 255-byte buffer is handed to dnsmasq's extract_name() in extract mode, which writes up to roughly 504 bytes. It is rated Moderate and is reachable from any query FTL answers itself.

Two settings move behind the command line

The behaviour change is the part administrators will notice. misc.dnsmasq_lines and webserver.advancedOpts can no longer be changed through the API or the web interface; they can still be set in pihole.toml, through environment variables, or with pihole-FTL --config. In other words, the two options that provided a foothold are now the two you must change at a shell.

The release carries a long tail of ordinary fixes as well: pi.hole and the local host name answering NODATA until a restart once the interface cache went stale, an infinite loop in the dnsmasq configuration test when debug.config is enabled, webserver workers spinning at 100% CPU in the mbedTLS debug callback, database connection leaks and counter skew, configuration write races, and memory-safety hardening in the netlink parsers, get_api_string(), base64_decode_update() and arp-scan. There is also a tidier API: wrong-method requests now return 405 with an Allow header.

None of the four advisories has been given a CVE identifier, so anyone watching vulnerability feeds for a number to act on will wait a while. Those feeds are not the fastest route here: the advisory pages list affected versions from 5.9 and 6.0 onwards and name 6.7.1 as the patched release, though their own numbering refers to FTL v6.7.2.

Our opinion

The most interesting thing about this release is the third advisory. Fixing a reported bug, reading the code around it and finding three more ways through the same door is what good maintenance looks like, and it rarely makes headlines because it produces nothing dramatic - just four closed holes and a slightly narrower configuration surface.

The awkward part is how the two serious bugs got there. Pi-hole is beloved precisely because it is tinkerable: you can bolt on dnsmasq directives, you can tune the webserver, and the whole point is that the tool trusts the person who installed it. A web form that can reach those options has to be more careful than the command line, not equally careless, and for a while FTL's form was the loosest lock on the door. Taking the two riskiest settings away from the browser is not a regression to grumble about. It is the project admitting, correctly, that the web interface was never the right place for them.