CVE-2017-14491 – Remote code execution in the DNS subsystem that can be exploited from the other side of the internet against public-facing systems and against stuff on the local network. The previously latest version had a two-byte overflow bug, which could be leveraged, and all prior builds had an unlimited overflow.
CVE-2017-14492 – The second remote code execution flaw works via a heap-based overflow.
CVE-2017-14493 – Google labels this one as trivial to exploit. It's a stack-based buffer overflow vulnerability that enables remote code execution if it's used in conjunction with the flaw below.
CVE-2017-14494 – This is an information leak in DHCP which, when using in conjunction with CVE-2017-14493, lets an attacker bypass the security mechanism ASLR and attempt to run code on a target system.
CVE-2017-14495 – A limited flaw this one, but can be exploited to launch a denial of service attack by exhausting memory. Dnsmasq is only vulnerable, however, if the command line switches --add-mac, --add-cpe-id or --add-subnet are used.
CVE-2017-14496 – Here the DNS code performs invalid boundary checks, allowing a system to be crashed using an integer underflow leading to a huge memcpy() call. Android systems are affected if the attacker is local or tethered directly to the device.
CVE-2017-13704 – A large DNS query can crash the software.
Raspbian repository already has fixes. Time to patch!
we take a fork directly from the dnsmasq project and implement it within FTL. the next release coming Soon™ will include these fixes provided you are on the latest update
$ pihole -v
Pi-hole version is v4.0 (Latest: v4.0)
AdminLTE version is v4.0 (Latest: v4.0)
FTL version is v4.0 (Latest: v4.0)
The dnsmasq binary on my rasbian stretch version is
$ dnsmasq --version
Dnsmasq version 2.76 Copyright (c) 2000-2016 Simon Kelley
Compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify
But as I understand pihole ships with a different patched binary that is called pihole-FTL
$ pihole-FTL --version
v4.0
I've tried the CVE-2017-14495 Vulnerability PoC Link
The PoC states that this only applicable if you have these options set in dnsmasq
dnsmasq is vulnerable only if one of the following option is specified: --add-mac, --add-cpe-id or --add-subnet.
As far as I know it isn't set anywhere in my dnsmasq.conf
After running the PoC within seconds my raspberry pi start overheating, became unresponsive and the CPU usage for the process pihole-FTL went from 0.3 to 100%
That is what I thought at first, that pihole somehow still using the distribution installed version of dnsmasq instead of "pihole-FTL" binary. but that is not the case, I can confirm that pihole is indeed using the patched binary shipped with pihole and dnsmasq binary is not running.
To further my test I installed pihole on an different linux distribution without dnsmasq installed so no preinstalled binary. installed and configured pihole on arch and tested the same PoC from a different computer with the exact same results, pihole-FTL cpu usage goes up to 100%, and it's basically DoS-ed.
So the next logical thing is to test upstream dnsmasq, so I installed it on seperate machine ran just the defaults configuration and tested the PoC and same results it's getting DoS-ed
$ dnsmasq --version
Dnsmasq version 2.79 Copyright (c) 2000-2018 Simon Kelley
So the problem isn't from Pihole at all. upstream dnsmasq is still vulnerable to CVE-2017-14495 I presume.
Thank you very much for finding this out! Could you inform the dnsmasq mailing list about this issue? dnsmasq v2.80 is getting ready for a release in the not too distant future and it would be good if this could be made clear until this release which will then be included in one of the next pihole-FTL releases.
