DNS decoding bug in dns-zone-transfer.nse fixed

[David Fifield <david () bamsoftware com>]

Today I got a Zenmap crash report and was fortunate that the submitter
agreed to send the XML file to me. I eventually traced the bug to
dns-zone-transfer.nse of all places. There was a decoding bug (fixed in
r12015) that caused all kinds of binary data to appear in script output.
Some of it made it into the XML file and made the file non-well-formed.
The bug was kind of interesting so I'll describe it here.

DNS zone transfers happen over TCP. When DNS goes over TCP, multiple
discrete messages can appear in one TCP stream. Each message is prefixed
by a two-byte length field so you can separate them (RFC 1035 section
4.2.2). Another part of DNS is message compression (section 4.1.4),
which allows a domain name to point back to a different name to complete
it. For example, a DNS message might have a record for insecure.org at
index 12 and one for svn.insecure.org at some later index. The record
for svn.insecure.org might be just "svn." with a pointer back to index
12 to finish it.

The bug was that the decoder interpreted index pointers as relative to
the beginning of the whole stream, not the beginning of the individual
message it appeared in. So if the stream contained, say, five messages,
and the fifth message had a pointer back to index 23, the decoder would
jump back to index 23 of the *first* message, not the fifth. More often
than not, that index contained some ASCII byte, which would be
interpreted as a length for the next domain name segment, and from there
all decoding hell would break loose, with binary control characters
being written to the output. One of these, 0x0C, was not protected by
NSE's escaping, made it into the XML, and caused the Zenmap crash.

I fixed the problem by breaking the stream up into discrete messages and
processing them one by one, never looking at the stream as a whole.
There was another minor bug that caused records to overwrite each other
in the output table when there was just one answer per message, which I
fixed. I can't remember anyone reporting this, aside from the crash
report today and one I got a few weeks ago. I fingerprinted the DNS
server that revealed the bug and it was "ISC BIND BIND 8.3.3".

There still remains the problem that a script can emit a 0x0C byte and
create invalid XML. Escaping it as  doesn't work because section
4.1 of the XML specification says "Characters referred to using
character references MUST match the production for Char," which
production doesn't include #xC. (Plus I tried it and the Python XML
parser chokes.) I notice that a lot of other characters in script output
backslash-escaped in the XML. Could this be done for 0x0C too?

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org