Discussion:
[Dnsmasq-discuss] CVE-2017-14495 PoC causes high CPU usage and denial of service against dnsmasq v2.79
Mouath Ibrahim
2018-10-08 01:58:00 UTC
Permalink
Hello,

I ran the PoC supplied by Google research team found here: https://github.com/
google/security-research-pocs/blob/master/vulnerabilities/dnsmasq/
CVE-2017-14495.py

and noticed immediately that dnsmasq process uses up 100% CPU usage and stops
responding to queries short after based on the original CVE the effect was
high memory usage but in this cause it was not.

note dnsmasq didn't have any of these options set "--add-mac, --add-cpe-id or
--add-subnet".

Fun note: run a local dnsmasq and set upstream to multiple dnsmasq servers,
local dnsmasq will forward these queries and cause the same effect

....
dnsmasq: forwarded query to 10.0.0.20
dnsmasq: forwarded query to 10.0.0.7
dnsmasq: forwarded query to 10.0.0.25
dnsmasq: forwarded query to 10.0.0.20
dnsmasq: forwarded query to 10.0.0.7
dnsmasq: forwarded query to 10.0.0.25
....

Regards,
Mouath Ibrahim
Kevin Darbyshire-Bryant
2018-10-08 07:24:59 UTC
Permalink
Post by Mouath Ibrahim
Hello,
I ran the PoC supplied by Google research team found here: https://github.com/
google/security-research-pocs/blob/master/vulnerabilities/dnsmasq/
CVE-2017-14495.py
and noticed immediately that dnsmasq process uses up 100% CPU usage and stops
responding to queries short after based on the original CVE the effect was
high memory usage but in this cause it was not.
note dnsmasq didn't have any of these options set "--add-mac, --add-cpe-id or
--add-subnet".
Regards,
Mouath Ibrahim
I am unable to reproduce. Against which version/s of dnsmasq did you try?


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
Mouath Ibrahim
2018-10-09 08:45:39 UTC
Permalink
Post by Kevin Darbyshire-Bryant
Post by Mouath Ibrahim
Hello,
https://github.com/
google/security-research-pocs/blob/master/vulnerabilities/dnsmasq/
CVE-2017-14495.py
and noticed immediately that dnsmasq process uses up 100% CPU usage and
stops responding to queries short after based on the original CVE the
effect was high memory usage but in this cause it was not.
note dnsmasq didn't have any of these options set "--add-mac, --add-cpe-id
or --add-subnet".
Regards,
Mouath Ibrahim
I am unable to reproduce. Against which version/s of dnsmasq did you try?
Cheers,
Kevin D-B
012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
I'm using 2.79 on arch linux machine with an i5 @ 2.53GHz
and a patched version from the Pi-Hole team v4.0 that is a forked from 2.79,
this one is running on my raspberry pi 3

I've also tested it on a manjaro linux and ended up crashing kde for me,
something with the bus could be not related.

I mainly run unbound as a recursive resolver so I thought that could be the
cause but it wasn't. I set up both machines (pi and arch) to use 8.8.8.8 and
1.1.1.1 as upstream and ran 3rd on my desktop to forward queries to both of
them.

dnsmasq couldn't resolve anything and eventually i had to stop it. cpu
overheats quick.

wish I can give more details, but I'm no expert.

Mouath
Matthias Andree
2018-10-09 16:09:25 UTC
Permalink
Post by Mouath Ibrahim
dnsmasq couldn't resolve anything and eventually i had to stop it. cpu
overheats quick.
If your CPU "overheats", you have hardware and system design issues, and
you need to fix those first independently. First thing to do is make
sure your system survives the prime95/mprime torture test for many hours
before testing anything else.
Matthias Andree
2018-10-09 16:16:34 UTC
Permalink
Post by Mouath Ibrahim
Hello,
I ran the PoC supplied by Google research team found here: https://github.com/
google/security-research-pocs/blob/master/vulnerabilities/dnsmasq/
CVE-2017-14495.py
and noticed immediately that dnsmasq process uses up 100% CPU usage and stops
responding to queries short after based on the original CVE the effect was
high memory usage but in this cause it was not.
note dnsmasq didn't have any of these options set "--add-mac, --add-cpe-id or
--add-subnet".
Can't reproduce on 2.79 with add-subnet=24,96 in the conf file. While
the attack is ongoing, dnsmasq is slow to respond (seconds), but returns
to normal once I terminate the .py script. I don't see a denial of service.
Loading...