Dnsmasq CVE's - fixes in Raspbian repo


#1

Seven vulnerabilities found (by Google researchers) in dnsmasq.

https://www.theregister.co.uk/2017/10/02/dnsmasq_flaws/

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!


#2

See german report @heise.de


#3

For what it may be worth.
I logged into my rapi with putty and ran
apt-get update
apt-get-upgrade


#4

No patches so far?

upstream dnsmasq already patched them


#5

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


#6

#7

Thank you guys :slight_smile:


#8

The linked webpage states:

Version 2.78, released today by developer Simon Kelley, has all the fixes you need, so you should be running that version.

As Pi-hole v4.0 includes v2.79, you are already using these patches since your last Pi-hole update. No need to wait for the next release :slight_smile:


#9

#10

I’m sorry to bring this up again.

I’m on latest version of pihole

$ 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%

Are these related ?

debug token is: zlejn0p0h0


#11

Most probably you are looking at your latest installed version of DNSmasq that is still installed but not active anymore.


#12

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.


#13

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.