Recently, Steve Gibson of grc.com has been developing a DNS test page
similar to Doxpara but intended to test in much greater detail for the
Dan Kaminsky DNS vulnerability. Currently, Steve's DNS test page crashes
certain routers, in particular some by Belkin, and mine by Ozenda. It
has been suggested (no more than a suggestion:
nntp://news.grc.com/grc.news.feedback) that these routers may
incorporate dnsmasq in their firmware, which, if true, would indicate a
possible buffer overrun, albeit one that may have been fixed some time ago.
Whilst the source of dnsmasq is accessible and very modest in size, it
would take me a lot longer than someone familiar with it to check for
such a bug, hence my posting. And setting up a rig to test it out would
also take some while.
Essentially what Steve's page does (www.grc.com/dns) is to provoke a DNS
query from the user's browser for <unique_13_char_id>.dns.grc.com. When
this hits Steve's DNS server, it returns 2 resource records:
- First a CNAME record giving the primary name of the queried FQDN as
a.{repeated 95 times}.<unique_id>.dns.grc.com
- Then an A record giving an IP address for the primary name.
At this point, my router crashes, and reboots some 60 secs later,
presumably forced by a heartbeat failure. I've uploaded a Wireshark
capture of this (using a non-vulnerable router) to
www.blueskylark.org/pcap.zip
If I provoke my router simply to do a DNS query for the horribly long
primary name, I get the result I expect, namely an A record just like
the one Steve returns but giving the IP address of the OpenDNS default
page (since I'm using OpenDNS), and my router survives. I conclude
therefore that it's being killed by the CNAME record, possibly because
the primary name is being stored in a fixed length buffer.
Looking through the change log, this could be an issue fixed in 2.17
(Nov '04), and it's not implausible that my router has firmware
containing a version of dnsmasq that old.
If anyone could throw any light on this I'd be most interested.
Regards - Philip
