Trying to track down malformed TXT sources

Thomas Cross <[email protected]>
Newsgroups gmane.network.djbdns
Message-ID <OF21EF470E.62F33FBD-ON87257521.00793DBD-85257521.007D1F11@us.ibm.com>

Greetings!

      I'm trying to track down the software that is causing some DNS
problems that I believe are associated with TinyDNS. Due to a recently
disclosed vulnerability in libSPF2 [1], IBM has started looking closely at
TXT responses received by networks that we manage. We've noticed a number
of malformed TXT responses "in the wild." Here are some examples that you
can easily check yourself with nslookup or dig:

whitebusfamily.co.nz - In this case the string length for the TXT string
appears to have been sent through a hex to decimal conversion when it
should have been sent through a decimal to hex conversion.

democracynow.org - In this case the string length for the TXT string is too
short.

wrongdiagnosis.com - In this case the second response simply has no string
length.

      I have not contacted any of these networks to ask them what DNS
server software they are using. They are not my customers and as they don't
maintain DNS server software themselves they are obviously not responsible
for this problem and they might not understand the nature of my request. I
used fpdns [2] to fingerprint the authoritative nameservers for each of
these domains and they all come back as TinyDNS 1.05. If you suspect that
fpdns does not properly identify TinyDNS then please let me know, but I am
operating under the assumption that this result is accurate.
      The fact that each of these examples is malformed in a different way
suggests that different software may be responsible for causing each of
them to be malformed. There appears to be an ecosystem of different
administration tools that allow users to manage TinyDNS database files. If
these servers are, in fact, TinyDNS servers, and they are using different
TinyDNS management programs, its possible that these programs may be
putting the wrong information into the TinyDNS database files, resulting in
malformed responses. Its also possible that there is a basic problem with
TinyDNS or the tinydns-data program that is resulting in these malformed
responses.
      These malformed responses are problematic for several reasons. The
first is that the software that is intended to parse them may fail to do so
correctly, resulting in the wrong behavior on computer networks. The second
is that they may cause the vulnerable libSPF2 software to crash. The third
is that they are hard to differentiate from attacks aimed at exploiting
said vulnerability. It would be best for all concerned if the responsible
software program or programs could be identified and fixes could be
distributed.
      I felt that the best course of action was to inform the TinyDNS
community about this problem and see if those of you who are more familiar
with this collection of code may be able to identify the responsible
software. If this analysis is correct, there are several potential courses
of action that could be taken, including a patch to TinyDNS that sanity
checks these string lengths before serving them. Of course, if you feel
that fpdns may have incorrectly identified these DNS servers it would also
be helpful to know that so that I can continue to investigate this problem.

Thanks,
Tom Cross
X-Force Research
IBM Internet Security Systems

[1] http://www.doxpara.com/?page_id=1256
[2] http://code.google.com/p/fpdns/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.